Contact management system and method

ABSTRACT

In an embodiment of a method of providing contact information, the method includes creating a contact record in a contact management system, where a process associated with a subject of the contact record and/or a recipient of data associated with the contact record is included in creating the contact record. A unique serial number is generated corresponding to the contact record and the serial number is conveyed to the recipient. A request by an application is received for the contact record from the contact management system corresponding to the serial number and data associated with the contact record is transmitted to the application.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation-in-part of U.S. patent applicationSer. No. 11/713,475, filed Mar. 2, 2007, which is a continuation-in-partof U.S. patent application Ser. No. 11/431,886, filed May 9, 2006, bothof which are incorporated by reference herein.

FIELD OF THE INVENTION

The present invention relates generally to contact management systemsand, more particularly, to systems and methods for selectivelydisseminating personal contact information.

BACKGROUND OF THE INVENTION

It is customary for individuals involved in personal, commercial orprofessional activities to exchange contact information with theirassociates. In a typical exchange, parties convey company names,personal names, job titles, telephone numbers, mailing addresses, emailaddresses, web page addresses and other contact information. The mode ofexchange usually includes stating the information verbally, writing downthe information or exchanging business cards or stationery.Traditionally, people have recorded and organized contact informationmanually by writing contact information into an address book or byaffixing a business card or a contact entry to a record keeping systemsuch as Rolodex®.

Today's computer-based contact management applications provide powerfulsearch and retrieval capabilities and user friendly applicationinterfaces, which make it convenient for individuals to enter contactinformation into their personal computers. Contact managementapplications are also found on portable devices including cellulartelephones, hand-held computers, VoIP (Voice over Internet Protocol)telephones, and web-based applications. Additionally, many businessesemploy enterprise resource planning systems, customer relationshipmanagement systems, sales force automation systems and other systemshaving contact management functionality. As a result, a large number ofcontact management applications are available for personal and businessuse, and individuals regularly utilize more than one contact managementapplication to store and maintain their contact information.

Entering contact information into multiple contact managementapplications requires a time-consuming and redundant manual data entryprocess. The high costs associated with manual data entry arewell-understood, and many prior art systems have been designed toaddress these concerns. For example, creating an electronic backup fileof a contact information database enables contact data to beautomatically restored to a contact management application if theapplication's database becomes corrupt. Backup files also enable datafrom one application to be imported into another application, providedthe file formats are compatible or translation from one format toanother is feasible.

Some prior art systems were designed to minimize the burden of manuallyentering contact information through use of specialized hardware andsoftware. In one approach, a business card scanner is used to scan thecharacters on a printed business card, and specialized Optical CharacterRecognition (OCR) software attempts to identify the scanned charactersand assign the identified characters to appropriate data fields in acontact management application. These systems require the purchase ofexpensive hardware and software, and human oversight is needed to ensureaccuracy of the recognized characters and placement of the data in theappropriate contact information field (e.g., the software may mistakenlyassign a fax phone number to a voice phone number field). These scanningsystems are typically adapted to work with personal computers and maynot be compatible with small computing devices such as personal digitalassistants (PDAs), handheld computers, and cellular telephones. Thesescanning systems are further limited to scanning printed business cards,thus contact information received through other conveyances (e.g.,verbal or handwritten) will still require manual data entry.

In another approach, a Uniform Resource Locator (“URL”) for an HTML webpage is encoded into barcode format onto a business card. A recipient ofthe business card scans the barcode into a web browser application toaccess a corresponding web page containing personal contact information.This type of system is described in Software Patent Institute SerialNumber TDB0901.0055, entitled “E-Business Card System,” and SerialNumber TDB1093.0202, entitled “Coded Business Cards.” Drawbacks of thisapproach include high equipment costs and the inability to use thesystem to input data into existing contact management applications.

Small, portable devices such as PDAs, handheld computers or cellularphones present additional problems for users needing to manually entercontact information. Cellular phones, for example, include numerickeypads in which a single key is used for entry of a number and multipleletters. As a result, a user may need to press the same key three orfour times to select a desired letter or number. Many pen-based PDAs donot include a physical keypad, but instead provide the user with a“virtual” keyboard on the PDA display that may be tapped with a pen.Some small computing devices include a miniaturized keyboard, but dataentry remains more challenging than using a full-sized keyboard on atypical desktop or laptop computer. Because of the difficulty inentering and managing data on small devices, many users manage contactinformation using a software application on a desktop computer. Thecontact information can be entered and viewed through the desktopapplication and then downloaded to compatible contact managementapplications on PDAs, handheld computers and cellular phones via a cableor wireless network transmission.

To facilitate the electronic exchange of contact information, theInternet Mail Consortium developed a specification for an electronicbusiness card data structure called a “vCard.” Users typically exchangevCards as attachments to email messages. The recipient of a vCard mayimport the vCard data into a contact management application thatsupports the vCard format. Drawbacks of the vCard include the difficultyof maintaining up-to-date contact information once conveyed, and thelack of compatibility with traditional modes of conveyance such as astandard business card, which still requires manual input of contactinformation.

Web-based contact management applications have also been introduced, butthese systems are not widely used due to drawbacks in the variousapproaches. In one approach, a subscriber enters contact informationonline, shares the information with other online subscribers, and maydownload other subscribers' contact information to a proprietaryapplication. Among the drawbacks of these systems are the use ofproprietary contact management software and the requirement that bothparties be subscribers to the web-based system.

Another approach offers add-on modules to contact managementapplications in widely-adopted email applications to assist inmaintaining current contact information. Examples of this type of systemare described in U.S. Pat. Nos. 6,694,353 and 6,701,348. In oneapproach, the contact management application notifies the user when theapplication sends an email message to a contact at an email address thatis not valid. The stored contact information may then be updated using asecondary email address for the intended recipient. In another approach,a user of an email application transmits an email message to each memberof the user's contact list requesting that each recipient verify theaccuracy of the recipient's current contact information. One drawback tothese approaches is that use is limited to certain softwareapplications, such as Microsoft Outlook. Another drawback is thatsending emails to recipients in a contact list may be inconvenient andannoying to the recipients, because the emails effectively serve as dataentry forms. When a recipient's contact information is stored inmultiple contact lists, the recipient may be inundated with emailrequests from the owner of each list to separately verify therecipient's stored contact information. Another drawback is that thesesystems require unique context-dependent identifiers for use in datalookup. Context-dependent identifiers include telephone numbers andemail addresses. A user who lacks a required identifier cannot store andshare contact information on these systems. Further, context-dependentidentifiers are subject to change, for example, as the user moves orchanges jobs.

Additional approaches involve generating a unique identifier for contactmanagement records. One approach offers a service that creates a vCardrecord and attaches an identifier to the record. This approach does notappear to offer any means of augmenting an application such as an emailapplication with data entry, update, synchronization or backupfeatures—relying instead on the widespread support for the vCard dataformat for data entry.

There is a significant market for applications that “synchronize”contact records between different devices. The known solutions have somesignificant disadvantages. The object of the solutions typicallyinvolves copying a contact record from one device and adding it toanother device. If the devices have the same record, these systemscompare the records to find the most up-to-date version. If the solutioncannot determine the most recent version, it typically presents a“conflict resolution” interface to the user, or provides a defaultsetting that enables one system's record to prevail. As people attemptto synchronize more than two devices, the number of records to compareincreases—impairing performance. When synchronization solutions attemptto retrieve data from applications behind corporate firewalls, thefirewalls can undermine the synchronization solution by blocking inboundnetwork requests. Additionally, as people increasingly adopt wirelesscommunications devices, they may find that uploading data from thesedevices may also present significant performance issues. Prior artsynchronization systems also have a tendency to create duplicaterecords, because users typically enter the minimum information necessaryfor a particular device (e.g., name and email address for emailapplications; name and phone number for phones).

Recent solutions have coupled synchronization solutions to electronicaddress book backup solutions. By providing a centralized server forsynchronization solutions, the centralized server stores the most recentcopy of each record on behalf of a user—enabling the user to enjoysynchronization and backup in a single application. By augmentingsynchronization solutions with a user interface that enables the user toupdate a record, these solutions purport to offer updates,synchronization and backup in a single solution. The drawbacks to thesesolutions include limited update functionality (i.e., it is up to theuser to enter the update), no ID-based automatic data entry, andreliance on traditional synchronization solutions.

Prior art also involves presence detection technologies that have theability to provide information of the presence of a device or user at aparticular location. U.S. Pat. Nos. 7,110,773 and 5,659,596 describesuch technologies. Presence detection technologies are also common withinstant messaging applications and VoIP solutions. However, presencedetection technologies do not appear to aggregated presence indicatorsof a user or device for a variety of different technologies and makethat information available to others directly in their contact addressbooks.

Therefore, there is a need for an improved system and method for contactmanagement.

SUMMARY OF THE INVENTION

In an embodiment of a method of providing contact information in thepresent invention, the method includes creating a contact record in acontact management system, where a process associated with a subject ofthe contact record and/or a recipient of data associated with thecontact record is included in creating the contact record. A uniqueserial number is generated corresponding to the contact record and theserial number is conveyed to the recipient. A request by an applicationis received for the contact record from the contact management systemcorresponding to the serial number and data associated with the contactrecord is transmitted to the application.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an embodiment of the contact management system andmethod of the present invention;

FIGS. 2 a-2 f illustrate embodiments of methods of the presentinvention;

FIG. 3 illustrates an embodiment of a method associated with a groupserial number;

FIG. 4 illustrates an embodiment of a method associated with a roleserial number;

FIG. 5 illustrates an embodiment of the contact management system andmethod of the present invention;

FIGS. 6 a-6 c illustrate search request and result data structures;

FIGS. 7 a-7 c illustrate contact request and reply data structures;

FIGS. 8 a-8 c illustrate an embodiment of a contact registry server ofthe present invention;

FIGS. 9 a-9 b illustrate data structures which may be used by thedatabase server of the contact registry server for storing data in thedata storage;

FIG. 10 illustrates a namespace redirect function of the presentinvention;

FIG. 11 a illustrates an exemplary network device as utilized with thecontact registry server of the present invention;

FIG. 11 b illustrates a contact management application of the networkdevice of FIG. 11 a;

FIG. 12 illustrates an embodiment of a contact reply and an associatednetwork device database record;

FIG. 13 illustrates an approval mask in accordance with the principlesof the present invention;

FIG. 14 illustrates an email application adapted for interaction withthe contact registry server;

FIG. 15 a-15 b illustrate third party application interoperability withthe contact registry server;

FIG. 16 illustrates an embodiment of a telephone that may be utilizedwith the contact management system of the present invention;

FIG. 17 illustrates an alternative embodiment of the contact managementsystem and method of the present invention as used with multiple networkdevices of a user;

FIGS. 18 and 19 illustrate a synchronization process of the presentinvention; and

FIG. 20 illustrates an embodiment of a web page with a banneradvertisement that incorporates the principles of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

As will be further described below, one aspect of the present inventionincludes a user creating and storing a contact record in a contactmanagement system, the system generating and storing a unique serialnumber corresponding to the contact record, and the user conveying theserial number to a recipient. The recipient may then enter the serialnumber into a network-enabled computer application and request, via theapplication, the corresponding record from the contact managementsystem. In response, the application receives data associated with thecontact record and stores the data in the application's database, orreceives an indication that approval from the owner of the contactrecord is required before the contact management system will transmitthe requested contact record.

In another aspect of the present invention, the recipient enters aserial number into a network-enabled computer application and requests,via the application, associated contact information from the contactmanagement system corresponding to the serial number. The contactmanagement system determines whether approval is required, and if so,responds to the recipient indicating that the request requires priorapproval from the owner of the contact information. Following anapproval of the request, the contact management system provides a methodto receive data associated with the contact information.

In another aspect of the present invention, a person does not have aserial number to enter into an application, and instead enters searchcriteria such as a person's name and phone number, email address,location (e.g., city, state and/or zip code), or other criterion. Thecontact management system responds by providing the serial numbers ofpotential matches. The person (now a serial number recipient) may selecta serial number to request a contact record from one of the matchingsearch results. In another aspect of the present invention, a usercreates and stores a contact record and serial number that includes“keyword” entries that enables other users to search for the contactrecord by keywords (e.g., plumber, pizza, gardening services, etc.).Keywords enable people to search for contact records of other users theydon't already know, thereby making the service useful for businessvendors, affinity groups, and other population groups.

In another aspect of the present invention, a method for receiving datafollowing a request for a contact record that requires the recordowner's approval includes the steps of automatically creating andstoring a request record with a unique serial number to identify therecord. The date and time of the request is logged in the requestrecord, and the requestor is prompted for additional information to bestored in the request record including the requestor's name, user nameand contact information (such as an email address) and other informationto facilitate the approval process, such as the requester's serialnumber or a note field for specifying the purpose of the request. Next,the user responsible for approving the request is notified and providedwith an interface for approving or rejecting the request. The requesteris provided with status updates of the approval process as needed. Afterthe request is approved, the corresponding contact information isavailable to be received by the requester.

In other aspects of the present invention, a requestor may receiveupdates for requested records, synchronize multiple devices byreplicating requests as an alternative to traditional synchronization,and restore an address book with previously requested records as analternative method of backing up contact records. The present invention,therefore, provides a means of searching for contact records, exchangingcontact information via serial numbers, approving requests, acceleratingdata entry, receiving updates, synchronizing multiple devices quicklyand securely, and providing a means of backing up and restoring contactrecords in one solution.

In other aspects of the present invention, technology which indicatesthe presence of a user at a location on a network indicates to therecipient of the serial number and contact record where the user may bemost easily reached.

Continuing with the description of the invention, an exemplaryembodiment will be described with reference to FIG. 1. A ContactRegistry Server (CRS) 10 provides contact management services to aplurality of network devices, such as network devices 30 and 32, througha network 20. The CRS 10 includes at least one computer adapted forcommunication with the network 20, and a data storage 18 storing contactinformation. The network 20 includes any system or systems capable offacilitating communications between the CRS 10 and the network devices30 and 32 and, in various embodiments, may include the Internet, awireless network, an intranet or a Public Switched Telephone Network(PSTN). Each network device 30 and 32 is adapted for communications withthe CRS 10 through the network 20, and may include a mobile telephone,personal digital assistant, vehicle navigation system, personalcomputer, portable computer, VoIP telephone or other network-enableddevice.

Referring to FIGS. 2 a-2 b and FIG. 5, an operation of the embodiment ofFIG. 1 will be described. In step 100, a first user, User A, registerswith the CRS 10. Registration provides User A with permission to store,maintain and disseminate contact information via the CRS 10. In oneembodiment, User A establishes communication with the CRS 10 through thenetwork device 30 by launching a web browser application and entering orselecting a Uniform Resource Locator (URL) of the CRS 10. Through webpages served by the CRS 10 to the network device 30, User A invokes anew user registration process.

User A enters a unique username and password combination for use by theCRS 10 to identify and authenticate User A in subsequent visits to theCRS 10. Alternatively, a temporary password is automatically generatedby the CRS 10 and may be changed later by User A after the first loginsession. In one embodiment, communications between the network device 30and the CRS 10 during the registration and login process are encrypted(e.g., using the Secure Socket Layer (SSL) protocol) providing a layerof protection against the unwanted access to, or dissemination of,personal contact information.

Referring to FIG. 1 and FIG. 2 b, through web pages served by the CRS 10to the network device 30, User A may invoke a user billing andverification process 101 by providing credit/debit card billinginformation to the CRS 10, including the name on User A's credit card.Through a gateway to a credit card transaction processor, the CRS 10charges User A's credit card and verifies User A's name and billinginformation. If User A's name and billing information are successfullyprocessed, the CRS 10 stores an attribute in the data storage 18indicating that User A's name is verified. In one embodiment, the CRS 10utilizes a third party address verification service. In one embodiment,the CRS 10 sends a confirmation email containing a hyperlink to the CRS10 along with a confirmation code. When the user receives the email andclicks the hyperlink, the CRS 10 validates that the specified email is avalid email address. In another embodiment, the CRS 10 is adapted toperiodically present a user interface to User A that prompts User A tocertify that the information in User A's user profile and contactrecords is true and correct. In other embodiments, a user may mail,email, or fax an official document such as a telephone bill to confirmthat User A is a real person. CRS 10 may provide various means ofindicating to the recipient of a serial number and contact record thatUser A is a real and interested person (i.e., as distinguished from atrial user or a “bot” that registers a user for surreptitious purposes).

In step 102, the CRS 10 generates a unique Serial Number (SN) 22 toidentify User A's personal contact information. The SN 22 may be anyunique identifier that is amenable for user input into a network device.It may include all numbers, all letters, an alphanumeric combination ofnumbers and letters, and is not limited to any particular sequence ofnumbers and/or letters. In the exemplary embodiment, the contactregistry server 10 generates a 9-digit SN 22. The SN 22 includes aconcise 8-digit alphanumeric string that is automatically generated oralternatively entered by User A, and a 1-digit alphanumeric errordetection code is appended. The CRS 10 queries the data storage 18 toensure that the generated SN 22 is unique—i.e., is not already in use bythe CRS 10 to identify personal contact information. An automaticallygenerated serial number 22 may incorporate naming conventions such asportions of the user's name and/or company name. User selected serialnumbers and the generation of serial numbers in accordance with namingconventions results in serial numbers being potentially easier toremember.

Alphanumeric characters enable the CRS 10 to issue concise serialnumbers 22 with an extensive address space that can accommodate millionsof users. For example, over 2.8 trillion serial numbers can be,generated using only 8 digits of case-insensitive alphanumericcharacters, where each character has 36 possible values (e.g., 0 through9 and A through Z). Alternatively, the SN 22 may include characters fromother character sets to accommodate different languages and cultures,including non-Western character sets such as Kanji. In one embodiment,an extended character set known as the Unicode character set is used.

When User B enters a 9-digit SN 22, the network device 32 can detectcertain data entry errors by verifying the accuracy of the errordetection code and notify User B when an invalid SN 22 is detected. Theerror detection code may be generated using conventional error detectionalgorithms such as CRC-8 (Cyclical Redundancy Check), a parity bitalgorithm, or other error detection algorithms.

In an alternate embodiment, the CRS 10 is adapted to generate serialnumbers 22 of varying length, and further adapted to generate an errordetection code that can check both the order of characters (e.g., as inCyclical Redundancy Check (CRC) algorithms) and the length of thepreceding string of characters—enabling the CRS 10 to set and determinevalid lengths for serial numbers in a system of variable length serialnumbers. The CRS 10 may also be adapted to receive a user-defined serialnumber 22, where the user can create an easily remembered or“personalized” serial number 22 with or without the benefit of anappended error detection character.

In one embodiment, the CRS 10 is adapted to generate serial numbers 22that are amenable to input on hand-held devices such as mobile phones.In one embodiment, the CRS 10 generates a serial number that is easy toinput when using Text on 9 Keys (T9). Since typing text on a cellularphone may require multiple key presses, for example, the number “2” mayalso represent the letters “a”, “b”, and “c” in ordinal precedence, theCRS generates a serial number 22 such that it prefers the first letteravailable on a T9 keyboard (e.g., the letters a, d, g, j, m, p, t, and ware preferred to letters c, f, i, l, o, s, v, and z).

After a unique serial number 22 is generated, a filtering function maybe applied by the CRS 10 to determine whether the SN 22 is valid basedon stored criteria. In one embodiment, the data storage 18 includes atable of offensive words, phrases and character patterns that areutilized by the filtering function to determine whether the SN 22includes a word or pattern of characters that may be deemed offensive.If the SN 22 is not valid, then a new SN 22 may be selected.

In step 103, User A may specify privacy and approval settings, whichdetermine whether User B may make a contact request for the serialnumber 22 via the CRS 10, and whether User A must approve a contactrequest before disseminating the contact record as a contact reply.

In step 104, a data record is created in the contact management databaseof data storage 18 for User A, and the unique serial number 22 is storedtherein. The record includes a field for the SN 22 and other fields thatare common in contact management databases, such as name, address,telephone number and email address. In one embodiment, User A isprovided an opportunity to populate the database record with personalcontact information through a web browser interface. The CRS 10 may alsostore additional information, such as user account information and userpreferences, including whether approval from User A is required beforethe CRS 10 disseminates User A's contact information to third partyrequesters.

Referring to step 106 of FIG. 2 a, the CRS 10 communicates the serialnumber 22 to User A via the web browser interface on the network device30 or, alternatively, via another supported method of conveyance, suchas an email message to User A. In alternate embodiments of steps100-106, third party applications may be adapted via plug-intechnologies, Web 2.0 mash-up technologies (Asynchronous JavaScript andXML) or other approaches to present the user interface for registeringwith the CRS 10 and generating a serial number 22 and contact record.

To protect against the unwanted dissemination of User A's unique serialnumber and contact information, the data may be encrypted before it isstored in the data storage 18.

In one embodiment, User A may create and store one or more user-definedfields in a record by specifying a field name and a value, asillustrated in FIG. 9 a. User-defined fields make it possible tocustomize a contact record (e.g., a contractor's license, an industrysector classification, etc.).

In one embodiment a search index manager processes the contents of thecontact record and data is added to the data storage 18 for use with asearch index processor. When a user submits search criteria in a searchrequest that corresponds to data in the contact record, the search indexprocessor may return the serial number 22 and other informationassociated to the contact record as a search result along with othermatching search results. These functions enable a person to search theCRS 10 to find a serial number 22 associated to a user without firstreceiving the serial number 22 from that user.

In one embodiment, the CRS 10 and the network devices provide searchfield(s) enabling a user to submit a person's name, telephone number,email address or other criteria and retrieve an associated serialnumber(s). The CRS 10 optionally enables registered users to specifywhether other users may search for their contact record by name,telephone number, email or other criteria to prevent undesired access totheir serial number and contact record.

In one embodiment, the CRS 10 provides interfaces that enable leadingsearch engines to generate and submit a search request and receive asearch result or a list of search results. Leading search engines may befurther adapted to make a contact request and receive a contact reply.Thus, a person may search for another person's contact informationconveniently by using widely adopted search engines in lieu of accessingthe CRS 10 directly.

In one embodiment, User A stores one or more text profiles in thecontact record 406 (FIG. 9 a) that provide User B with informationdistinguishing User A from other users (e.g., when User A has a commonname such as “John Smith”). The text profile does not require approvalfrom User A to view its contents. In one embodiment, User B searches forUser A's contact record without the benefit of User A's serial number 22by inputting search criteria and submitting a search request. The CRS 10via a search index processor provides a search result with multiplerecords—e.g., numerous serial numbers from different users named “JohnSmith”. Without additional information, User B may not know which serialnumber to request. User B can examine the profiles presented with thesearch results to help determine which serial number corresponds to UserA. In another embodiment, User B receives a request from User A, butcannot distinguish User A from other users without the benefit ofadditional information. User B can examine the profile presented withthe request to determine if the serial number corresponds to User A.

Referring to step 108 of FIG. 2 a and FIG. 5, User A conveys the serialnumber (SN) 22 to User B. User A may print the SN 22 on a business cardand provide the business card to User B, type the SN 22 into an emailmessage and send it to User B, verbally convey the SN 22 to User B orprovide the SN 22 through another mode of conveyance. In one embodiment,the SN 22 is conveyed, along with an associated trademark thatidentifies the source of the SN 22 and the associated CRS 10. Forexample, User A may convey the SN 22 in the form “SyncUp: JDOE25Z2C,”where “SyncUp” is a promoted trademark identifying the source of the SN22, making it clear what the number conveys. In this embodiment the SN22 isn't just a serial number printed on a business card, displayed inan email, or conveyed verbally, it is conveyed in association with atrademark to distinguish it from other serial numbers and addresses suchas email addresses and phone numbers.

Referring to step 110 of FIG. 2 a and FIG. 5, User B enters the serialnumber into a contact management application on network device 32. Inone embodiment, User B launches the personal contact managementapplication on the network device 32 that includes a blank serial numberinput field identified by a common name or trademark. The personalcontact management application is adapted to transmit an entered serialnumber 22 to the CRS 10 and requests corresponding contact informationassociated with User A. User B can rely on the accuracy of theinformation entered into the CRS 10 by User A, which presumably has beenverified and kept current by User A.

In one embodiment, another security measure implemented by the CRS 10includes detecting contact requests with random or invalid serialnumbers, and denying access to users and/or network devices 30-32 whoattempt to access personal contact information without authorizationfrom the CRS 10 or the user associated with the contact information. Forexample, a registered user of the CRS 10 may be denied access to thesystem after numerous failed attempts to enter a valid serial number 22.Invalid serial numbers may be detected, for example, if the enteredserial number 22 includes too many or too few digits, if the serialnumber 22 has not yet been assigned to a user, or if an error detectioncode is invalid. In one embodiment, the CRS 10 first processes eachrequest as a search request, and the user may make a contact request byselecting a serial number 22 from the search results. The CRS 10 mayemploy search engine capability to ensure that a user never directlysubmits an invalid serial number 22, thus, improving both performanceand security.

The contact request is transmitted from the network device 32 to the CRS10 and may include a “User ID” for authentication of the requestor, a“Device ID” to identify a network device for logging and synchronizationof stored contact information, a “Reply Type” or a “Device Type” foridentifying a data format or protocol associated with the network device32, a “Request Type” indicating if the contact request is for a newrecord, an update, or a deletion (among other possible request types),and the requested serial number 22.

In another embodiment, the contact request includes a category (e.g.,work, home, personal) to associate the requested serial number 22 with arequest context. In this embodiment, synchronization requests can filtercontacts by category so that network clients 30 can synchronize only asubset of the contact records (e.g., only synchronize “work” contacts tothe user's cellular phone). In one embodiment, a network device isadapted to provide a default categorization to a requested contact(e.g., if the network device is a social blog, the network devicecategorizes the requested contact as “friend” by default, etc.). Inanother embodiment, when User B requests a contact, the CRS 10 isadapted to categorize the contact automatically according tolocation-based attributes (e.g., all contacts within a particular city).

The contact requester may also offer one of his or her serial numberswhen making a request for the contact information of another user. TheCRS 10 may present the offered serial number to the user associated withthe requested serial number, and the user may accept or decline theoffered serial number. In one embodiment, the act of offering the serialnumber electronically serves as approval criteria if the offered serialnumber would otherwise require approval before disseminating contactinformation.

In one embodiment a request to the CRS 10 expresses the serial number 22in Uniform Resource Name (URN) syntax (i.e., RFC 2141), such as“SyncUp://JDOE24Z/C,” where the “SyncUp://” portion of the syntaxrepresents a namespace. Referring to FIG. 10, if the instant system 10 aprocessing the contact request does not have records within thatnamespace, it may relay the request to a system 10 b that does storerecords with the provided namespace. In one embodiment, a namespaceredirect function looks for the address of a separate system using anamespace map record, and redirects the request to that system andprovides the contact reply to the requester. Thus, with the presentinvention, users may utilize one service to access the records ofanother service via the namespace parameter (e.g., SyncUp://) prior tosubmitting the serial number 22.

In one embodiment, the contact request and contact reply further includea 2-digit or 3-digit language abbreviation and a 2-digit countryabbreviation. The 2-digit country code may be specified in accordancewith International Standards Organization (ISO) ISO 3166-1 (e.g., US,UK, JP, etc.), and the language may also be specified in two digits inaccordance with ISO 639-1 or three digits in accordance with ISO 639-2(e.g., DUT: Dutch; ENG: English; FRA: French; JPN: Japanese.)Alternatively, the contact request and contact reply further include acharacter encoding in accordance with ISO 8859, UTF-8, UTF-16, ISO 2022,and others. For example, a request from a Russian-speaking user of acontact management application who resides in the United States mayinclude the term “RUUS” (Russian+U.S.) or ISO 8859-5 (Cyrillic). In thismanner, a user doing business in different countries, across differentlanguages, can convey serial numbers 22 encoded in language charactersets other than the Roman Alphabet, and the CRS 10 can correctlyinterpret the serial number 22. Additionally, the contact record maysimilarly be encoded in different languages.

In one embodiment, a contact record is stored in a first language, suchas English, and the CRS 10 receives a contact request identifying thecontact record, the request including a code for a second language code,such as Japanese. In this embodiment, the CRS 10 is adapted to translatethe stored contact record from the first language to the second languageand return the contact record as a contact reply in a format associatedwith the second language code.

In one embodiment, User A resides in one country and User B resides inanother country. When User B makes a request for User A's contactinformation, the CRS 10 appends international calling numbers (e.g., +39in the case of Italy) and adds or removes any necessary prefixes tonational area codes or local numbers as required by the conventions ofthe phone systems in various locales. In one embodiment, the CRS 10 isadapted to translate phone numbers using ITU-T E.164 country codes andidentification codes. Adding international prefixes makes it possiblefor User B to call User A without the difficulties that could beassociated with modifying a record to add an international prefix.

In alternate embodiments, approval processes limit access to User A'scontact information by requiring prior approval before the contactinformation is disseminated in response to a user request. The approvalprocesses allow registered users to control the dissemination of theircontact information, while maintaining a desired degree of privacy andconfidentiality.

Referring to FIGS. 2 c-2 f, various approval processes may limit accessto User A's contact information by requiring prior approval before thecontact information is disseminated in response to a user request. Theapproval processes allow users to control the dissemination of theircontact information, while maintaining a desired degree of privacy andconfidentiality. In the various embodiments, User B launches a personalcontact application on a network device 32 in step 111 and enters searchcriteria, which is submitted as a search request to the CRS 10. In step113, the personal contact information application receives searchresults from the CRS 10. In step 115, User B selects User A's serialnumber 22 from the search results, thereby submitting a contact requestfor User A's serial number 22 to the CRS 10.

In one embodiment, User A defines a set of approval criteria to beapplied to one or more contact records by the CRS 10. After receiving acontact request (FIG. 7 a) for a contact record 406, the CRS 10determines at step 117 whether approval criteria have been specified forthe contact record. If approval is required, the CRS 10 proceeds to step119 until the approval criteria is met 119 (or disapproved). Forexample, manual approval by User A may be required prior to releasingthe requested contact information in step 121. While the CRS 10 awaitsapproval from User A, the CRS 10 may respond with an “approval pending”message to User B.

Referring to FIG. 2 d, at step 118 the CRS 10 receives a contact requestand determines that approval is required. At step 120, User B isprompted to provide a note and to optionally offer one of User B'sserial numbers 22 to User A. In step 122, the CRS 10 presents User Awith the contents of an approval record and User A approves the request,which spawns a contact reply to User B. In step 124, the CRS 10 presentsUser A with the contents of an offer record and User A accepts theoffer, which results in a contact request followed by a contact reply.

Referring to FIG. 2 e, at step 118 the CRS 10 receives a contact requestand determines that approval is required, where the criteria forapproval is a monetary payment by User B. In step 125, User B ispresented with a user interface prompting User B to supply and/orauthorize the use of credit card and billing information. Uponverification of payment, the CRS approves User B's request at step 127.Such an approval process may generate revenue for the service provider,and/or User A.

Referring to FIG. 2 f, an exemplary embodiment of a web browser-basedapproval process will now be described. In step 150, User B requests acontact record by submitting a serial number 22 through a compatible enduser application, such as by navigating a web browser application to theURL of a contact record request page or selecting a search result withina web page. If approval is required, User A, must approve the requestbefore the CRS 10 can release the contact record to User B (step 152),then the CRS 10 determines the source application of the contact recordrequest in step 156 and responds to User B with an “Approval Required”message in step 158. If no approval is required (step 152), then the CRS10 responds with the requested record in a format compatible with therequesting application in step 154—a web page or a download for importinto the requesting application. By contrast, other embodiments providedifferent formats such as an XML message, an email or SMS message, or anSS7 packet.

Similarly, the presentation format of the “Approval Required” messagemay be selected based on the source application. For example, if the CRS10 determines that the contact request originated from a contact recordrequest web page associated with the CRS 10, the “Approval Required”message may include a web page that informs User B that approval by UserA is required. The web page may include a name field identifying User Bto User A, an email field indicating an email address where User A sendscontact information if approved, and other fields for collectinginformation from User B to assist User A in approving or rejecting thecontact request such as a note field for use by User B to provide anexplanation or purpose for the contact record request to User A. In oneembodiment, the web page includes a field for User B's serial number 22,enabling User B to offer his or her contact serial number to User A.

In one embodiment, User B enters his or her name, email address, andother requested information into the “Approval Required” web page andsubmits the information to the CRS 10, which receives the information instep 160. In step 162, the CRS 10 generates an approval record to trackthe request-approval process. The fields of the “Approval Required” pagemay contain pre-populated data if User B is logged into the CRS 10, orif User B's contact information is available in a cookie or viaauto-fill technologies.

In step 164, the CRS 10 notifies User A that there is a pending requestthat requires User A's approval. In one embodiment, the CRS 10 sends anemail notification to User A. In another embodiment, the CRS 10 notifiesUser A through an end user contact management application, such as uponlogin by User A onto the CRS 10 or through a resident service module onUser A's network device 30.

In step 166, User A approves or rejects (or possibly ignores) User B'srequest. In one embodiment, User A approves or rejects User B's requestby logging onto the CRS 10, navigating to an approval/rejection webpage, selecting the approval record 424 (FIG. 9 b) submitted andpressing either an “Approve” or “Reject” user interface button. If UserA approves or rejects the request, the CRS 10 changes an “ApprovalStatus” field in record 424 depicted in FIG. 9 b from “unapproved” to“approved”, or alternately from “unapproved” to “rejected” if User Arejects User B's request.

In step 168, the CRS 10 transmits a message to User B indicating theresult of the approval process. In one embodiment, if User A approvesUser B's request, an email message is sent to User B including User A'scontact information. The email may include the contact information asunstructured text, as a structured text record attachment (e.g., XML orvCard), or in another format. In alternate embodiments, the emailmessage will include a URL or hyperlink to an approved request web pageor a file that enables User B to retrieve the contact information fromthe contact registry server 10. The messages transmitted between the CRS10 and User B, including associated email and web pages, may furtherinclude advertising which generates revenue for the CRS 10 provider. Inan alternate embodiment, a network device adapted for communication withthe CRS 10 through an application plug-in receives the result of theapproval process in a structured text record such as XML or vCard thatis compatible with the requesting application.

In one embodiment, User A defines a Personal Identification Number (PIN)or concise password to be applied to one or more contact records by theCRS 10. When receiving a request for a contact record, the CRS 10 maydetermine that approval criteria is met for the contact record if therequest contains a valid PIN or password, and if so, will provide therequested information. This may be beneficial in a situation, forexample, where a person may convey their serial number 22 for a recordthat requires approval and where the user is not able to make animmediate and needed approval electronically (e.g., when providing aserial number to a receptionist at a hotel, car rental agency, etc).

In an alternate embodiment of an approval process, User B may requestaccess to and use of User A's contact information in accordance withlegislative mandates requiring User B to provide User A with a means ofcontrolling access and use of User A's information, such as the EUDirective on Data Privacy or the Health Insurance Portability andAccountability Act (HIPAA). In this embodiment, approval by User Aeffectuates a binding agreement whereby User A will continually provideUser B with accurate information, and User B may only use User A'sinformation in a manner specified by User A. In one embodiment, if UserA rescinds approval to User B, User B is directed by a message from theCRS 10 to cease use of User A's information and possibly to remove UserA's contact information from User B's devices.

In one embodiment, the CRS 10 provides a “Send to a Friend” feature thatenables a user to send his/her serial number 22 to other individuals viaemail. In one embodiment, the CRS 10 accepts an email address from UserA, and contains logic to determine if the submitted email addresscorresponds to a registered user, such as User B. If the submitted emailaddress corresponds to a registered user, such as User B, the CRS 10offers User A's serial number 22 to User B automatically using the offerprocess described herein instead of sending User B an email message. Inanother embodiment, the CRS 10 contains logic to determine if the emailaddress exists in an anti-spam list, and prevents the sending of anemail message if the email address is present in the anti-spam list. Ifthe submitted email does not correspond to a registered user and is notpresent in an anti-spam list, the CRS 10 sends an email messageincluding User A's serial number to User B. In one embodiment, the CRS10 adds User B's email address to an approval record with its approvalstatus set to “approved” on behalf of User A. This enables User B torequest User A's contact information and receive immediate approval uponsubmitting the email address, or receive an offer for User A's contactinformation upon registering as a new user with the CRS.

Referring to FIG. 14, in another embodiment User A has an emailapplication adapted for interaction with the CRS 10. The emailapplication contains logic to parse the email application's “Sent Email”folder for “Send-To” email addresses or alternatively to store a copy ofsent email addresses as they are sent. In step 560, User A launches theemail application and sends an email. In step 562, the plug-in thatinteracts with the CRS 10 stores a copy of a “Sent To” email address. Instep 564, the plug-in sends the email address along with User A's serialnumber 22 to the CRS 10. In one embodiment, the email and serial number22 are sent by the plug-in to the CRS 10 automatically. In anotherembodiment, the plug-in prompts User A asking if User A wants topre-approve the person associated to the email address. In step 566, theCRS receives an email address and generates an approval record with theapproval status set to “approved” and determines whether the emailaddress corresponds to a user's account. If the email address does notcorrespond to a user account, the email address is stored in theapproval record and used to approve the person associated to the emailaddress after they sign up at step 568. In alternate embodiments, theapproval record may be used to approve a non-user requesting a contactwhere the contact information is disseminated to the requester at thesame email address. Alternatively, the CRS 10 disregards the emailaddress if the person associated to the email address is not a user. Instep 570, the CRS 10 determines that the person associated to the emailaddress is a user, such as User B, and pre-approves (or approves) arequest by User B for the contact information associated to the serialnumber 22 submitted at step 564.

In an alternate approach, User A via the email application sends aserial number 22 to User B in conjunction with a signed Triple DataEncryption Standard (DES) key generated by the CRS 10, User B's emailaddress (which can be used for authenticating User B with the CRS 10),and a timestamp used to limit the duration of approval. Upon receipt ofthe message, User B may request the serial number from the CRS 10 viathe key, and the CRS 10 may authenticate User B via the email portion ofthe key. Advantages of these approaches include approving anticipatedrequests before they occur (as User A may include a serial number 22 inthe email); and User B may forward an email sent by User A to User C,but User C is not automatically approved by User A in spite of User C'sknowledge of User A's serial number 22.

In other embodiments, approval criteria include user specified rules forautomatic approval. For example, approval may be limited to requesterswho are registered users of the CRS 10, to requesters whose contactinformation is stored in User A's address book, or other criteriaspecified by User A. User A may also set up approval levels that differbased on the content of the requested information. For example, User Amay have business contact information via one serial number 22 that doesnot require approval and another contact record and serial numberconsisting of home information that does require approval.

Referring to FIG. 8 c, in one aspect of the present invention, the CRS10 contains “data mask” logic 378, which enables User A to disseminateparticular data attributes within a contact record while preventing thedissemination of other attributes (e.g., providing only phone numbers)by applying a data mask to a contact record prior to generating acontact reply. In one embodiment, the CRS 10 provides logic enablingUser A to create a data mask, to specify data attributes to include in aresponse, to provide the data mask with a name, and to store the datamask in the CRS 10. In one embodiment, the CRS 10 provides logic 378enabling User A to select a data mask from a plurality of data masks,and to apply the selected data mask to a contact record prior todisseminating a response message to User B. Referring to FIG. 13, a datamask may consist of all the attributes of a contact record where thefield values are true/false or yes/no to indicate whether a contactreply should include the values. When assembling a contact reply, thedata mask is applied as shown in FIG. 13. User A may apply a default“data mask” to a record for added convenience. User A may also select amask from a plurality of masks when approving a request for a contactrecord or when offering one of User A's contact records to another usersuch as User B. In an alternate embodiment, a data mask is used todetermine which fields within a contact record may be searched by otherusers, such that the search index manager 356 only includes fieldsmarked “true” or “yes” in the search index database.

In one scenario, User A is a privacy conscious person who may findapproval processes unsuitable (e.g., a celebrity, a politician, etc.),because disseminating the serial number 22 may result in thousands ofrequests from unknown individuals—creating more labor than User A wouldfind acceptable. In an alternate embodiment, User A may precluderequests for the serial number 22 altogether. Instead, User A mayrequire User B to provide User B's serial number 22 or username to UserA, and User A will offer one of User A's contact records to User Belectronically by specifying the serial number 22 offered and eitherUser B's username or one of User B's serial numbers 22 in an “offer”type request to the contact registry server 10. User B may accept ordecline the contact record offered by User A. User A may exercise the“offer” type request irrespective of whether User A precludes requestsfor User A's serial number and contact record.

In one scenario, User A wishes to refer User B's serial number andcontact record to User C. User A selects User B's contact record andserial number from a list within the contact manager 528 (FIG. 11 b) ofa contact management application 520 on a network device and invokes a“refer” type request, which requires User A to further specify anotheruser who will receive the referral. User A selects a contact record andserial number for User C. The contact management application via thecontact request manager 530 submits the “refer” type request to the CRS10, which stores the “referral” in a record associated to User C,enabling User C to make a request for User B's contact record via theserial number. In one embodiment, the “refer” type request includes UserA's name as the referring party. This notifies User B and User C thatUser A provided the referral.

In one scenario, User A and User B each have contact informationrecords, which require their respective approvals before disseminatingcontact information to requesters. User A has previously requested UserB's contact information and received approval, and User B has previouslyrequested User A's contact information and received approval. In oneembodiment, User A deletes the contact information he/she requested fromUser B. Referring to FIG. 8 c, the CRS 10 is adapted to respond to thiscontact event by contact event manager 355 looking up requests made byUser B for User A's contact information, and presenting User A with theopportunity to rescind approval to User B such that User B will not beable to receive updates to User A's contact record in the future. Inanother embodiment, User B is notified of User A's rescission ofapproval for User A's contact record. The CRS 10 is adapted to respondto this contact event by looking up requests made by User A for User B'scontact information, and presenting User B with the opportunity torescind approval to User A such that User A will not be able to receiveupdates to User B's contact record in the future. Deleting a person'scontact record or receiving a rescission of approval for a contactrecord may indicate the end of a personal relationship such that the CRS10 should present users with the opportunity to rescind approvalsreciprocally.

In one embodiment, the CRS 10 detects a contact event by contact eventmanager 355 (FIG. 8 c) such as a contact record update and spawnsadditional processes. For example, the CRS 10 may present a user whoupdates his/her contact record with a list of additional processes theuser may invoke, such as updates to tax authorities, postal authorities,or motor vehicle agencies to update tax forms, mailing addresses, ordriver's licenses respectively. Other processes may involve enrolling inanti-spam lists, national do-not-call lists, or to provide direct mailmarketers or other vendor relationships with updates to the user'scontact information. The update contact event manager 355 (FIG. 8 c) maypresent the user with commercial offers such as offers for new businesscards or stationery. In another embodiment, the update manager 355 (FIG.8 c) helps to notify organizations of the user's new contact informationin accordance with EU Directive on Data Privacy or the Health InsurancePortability and Accountability Act (HIPAA)—ensuring that organizationsmaintain accurate and up-to-date information on the user. In thisembodiment, the update contact event manager 355 (FIG. 8 c) may spawnemails or mail notices. Additionally, the CRS 10 may selectively presentprocesses to users depending upon criteria within the contact record(e.g., a Pennsylvania resident changing an address within Pennsylvaniawould not find a California DMV update process useful). In anotherembodiment, the CRS 10 may be adapted to invoke the foregoing processeswith Third Party Applications (TPAs) using Web 2.0, “mashup” or otherintegration techniques.

In one embodiment, a contact record may be requested through a hyperlinkto a CRS 10 request page, including at least one search parameter. Forexample, a signature block in an outbound email may include a hyperlinkto the CRS 10 request page along with the sender's contact serialnumber. An email recipient may make a contact, record request byclicking the hyperlink.

Referring back to FIG. 2 a, after access to User A's contact informationis granted to User B, in step 112, the CRS 10 retrieves User A's contactinformation—identified via the received serial number 22—from the datastorage 18. The CRS 10 transmits the contact data (e.g., first name,middle name, last name, telephone number, email address, etc.) in astructured information record, such as an XML file, suitable for mappingto data fields in User B's contact database. The format may be specifiedby User B's contact management application through a code in the contactrequest.

Referring to FIG. 12, the response message may contain a “digest” 552that signs the contact information record using Public KeyInfrastructure (PKI) signature technology. This “signature”authenticates the contents of the contact record and may indicate itscreation date, last login date and last modified date among otherattributes. This digest allows the receiving application to determinethat the received contact information record was created and/or modifiedon the server by the registered user and not another party duringtransit. The digest may also enable the receiving application todetermine whether the user associated to the contact record certifiedthe contents of the information, identify the user's service level, ordetermine authorized uses of the information (e.g., the EU Directive onData Privacy, HIPAA, etc.). The digest helps the recipient determinewhether the contact record contains reliable information among otheruses.

The received contact information is imported into User B's personalcontact database in step 114 of FIG. 2 a. As illustrated in FIG. 12, theconveyed serial number 22 is stored in a database table 554 that atleast includes an identifier of an associated contact record, such as aunique database record index or primary key. An example of a mappingfrom an XML-formatted contact reply message 550 to a network devicedatabase record 556 and cross-reference file 554 is also illustrated inFIG. 12. In one embodiment, the received contact data is entered as anew record and the serial number 22 is stored in a cross-reference file554 along with the record ID or index of the new record within thecontact management application. The cross-reference file 554 facilitatesa link between the contact data stored on each network device and thecorresponding data stored in the CRS 10, which is useful for updates,synchronization (i.e., the delete requests) and other linked requests.

In one embodiment, User A may wish to provide User B with an alternativecontact record and serial number 22 to replace a previously requestedcontact record and serial number. The contact manager 350 (FIG. 8 c) isadapted to enable User A to store a replacement serial number field in apreviously requested contact record using the logic to manage thecontact 352. The contact request handler 370 is also adapted to enablethe request processor 373 to request the alternative contact record inlieu of the original record. The contact request manager 530 and contactcross reference 532 of the contact management application 520 on thenetwork device are modified to process a “replace” response type. In oneembodiment, the network device prompts User B to allow one serial numberand contact record to replace another serial number and contact record.The contact management application 520 facilitates the replace operationby removing the previous serial number from the cross reference recordand replacing it with the alternate serial number, then, it proceeds toupdate and store the contact record contents.

In one embodiment, the CRS 10 is adapted to facilitate thesynchronization of a plurality of personal contact databases associatedwith a user. The CRS 10 logs each request for contact information fromeach network device 32 application. When one of the network deviceapplications sends a synchronization request to the CRS 10, therequesting application will automatically receive contact information,deletion instructions, or other information requested by othernetwork-enabled applications associated with that user. In oneembodiment, a request results in a contact reply container with multiplecontact replies.

In another embodiment, the CRS 10 includes a service providing for theremote deletion of contact information stored on network devices andapplications. For example, if a user discontinues the use of anapplication, or if a network device 32 is lost or stolen, the user maywish to delete the associated contact information on that device andblock future contact requests to the CRS 10 from the application ordevice to prevent misuse of the stored information. In operation, aregistered user of the CRS 10 initiates the remote deletion service andidentifies the applications and devices targeted for contact informationdeletion. The CRS 10 logs the identified devices and applications andprevents future contact requests thereby. The deletion of the remotecontact information may be implemented through the update andsynchronization features described herein (e.g., by identifying theremote records as deleted or updated as blank records) or by adaptingthe CRS 10 to transmit deletion instructions to one or more of thenetwork-enabled applications that support remote deletion of contactinformation.

In one embodiment, a serial number is used to identify a role within anorganization (e.g., purchasing manager, accounts receivable clerk, etc.)rather than a contact record for a particular individual. A role serialnumber is assigned by the CRS 10 and mapped to an existing contactserial number in a role database record 414 (see FIG. 9 a). A networkdevice 32 requesting contact information associated with a role serialnumber will receive the contact information of the individual contactrecord in response. Referring to FIG. 8 c, the role manager 390 includesprogram logic for creating a role 392 and managing a role 394. In oneembodiment, the “generate serial number” function 353 is adapted togenerate a serial number for the role, and the request processor 373 isadapted to process role requests and replies.

Referring to FIGS. 1 and 4, an embodiment of the operation of roleserial numbers will be described. User A establishes a role through aninterface on the CRS 10 in step 250. The CRS 10 generates a unique roleserial number in step 252 and transmits the role serial number to User Ain step 254. In step 256, through a second interface on the CRS 10, UserA enters a serial number 22 associated to an individual contact record.The referenced individual contact serial number is mapped to the roleserial number managed by User A. In one embodiment, the CRS 10 requestsapproval to include the individual contact in the role, as required. Instep 258, User A conveys the role serial number to a third party, suchas User B, to disseminate contact information.

In step 260, User B launches a personal contact management applicationand enters the role serial number. In step 262, the personal contactmanagement application retrieves individual contact informationassociated with the entered role serial number from the CRS 10. The CRS10 receives the role serial number from the personal contact managementapplication and retrieves the corresponding contact record from thedatabase. The individual contact record is transmitted to the personalcontact management application, such as through a contact reply. In step264, the received contact record is stored in the personal contactdatabase. User A may substitute serial numbers as individuals changeroles within an organization.

In one embodiment, a plurality of contact serial numbers, such as thosebelonging to company employees, may be grouped under a single groupserial number. A group serial number is assigned by the CRS 10 andmapped to a plurality of existing contact serial numbers or group serialnumbers in a group database. Further, a network device requestingcontact information associated with a group serial number will receive aplurality of associated contact records in response. Referring to FIG. 8c, the group manager 380 includes program logic for creating a contactgroup 382 and managing the contact group 384. In one embodiment, the“generate serial number” function 353 is adapted to generate a serialnumber for the group, and the request processor 373 is adapted toprocess group requests and replies.

Referring to FIGS. 1 and 3, an embodiment of the operation of groupserial numbers will be described. User A establishes a contact groupthrough an interface on the CRS 10 in step 200. The CRS 10 generates aunique group serial number in step 202 and transmits the group serialnumber to User A in step 204. In step 206, through a second interface onthe CRS 10, User A enters one or more serial numbers 22 of potentialgroup members. The group members may be referenced by individual contactserial numbers, role serial numbers and group serial numbers which aremapped to the group serial number managed by User A. In one embodiment,the contact registry server 10 requests approval to include individualcontact or group serial numbers in the group, as required. In step 208,User A conveys the group serial number to a third party, such as User B,to disseminate contact information for the group of users.

In step 210, User B launches a personal contact management applicationand enters the group serial number. In step 212, the personal contactmanagement application retrieves individual contact informationassociated with the entered group serial number from the CRS 10. The CRS10 receives the group serial number from the personal contact managementapplication and retrieves the corresponding contact records from thedatabase. The group of individual contact records is transmitted to thepersonal contact management application, such as through a contact replycontainer. Through this process, the plurality of contact records (eachof which may include more than 100 characters) associated with the groupmay be retrieved by entering a concise serial number saving asignificant amount of time and effort. In step 214, each of the receivedcontact records is stored in the personal contact database. In oneembodiment, the personal contact management application maintains amapping of each contact record to its individual serial number, and eachindividual serial number to the group serial number.

Another embodiment of the present invention includes a Taskbar ServiceModule (TSM) such as those available on Windows-enabled computers, whichallows the user to activate a taskbar service from a taskbar, search foror make requests for contact information, and approve requests forcontact information without the aid of an internet browser. A TSMprovides a convenient way to access application functionality availableto the CRS 10 or a network device without requiring the user to open abrowser, navigate to the CRS 10, provide authentication credentials, andnavigate to the particular functionality the user wishes to exercise. Ataskbar module also alleviates the need to access other applications,such as email or cellular phone address books adapted for use with theCRS 10. Instead, the user may click on an icon on the taskbar to launcha TSM that will maintain a session with the CRS 10. In one embodiment,the user may enter a serial number 22 and request contact informationthrough the TSM, or approve requests for the user's information asnecessary. The TSM stores the username, password, and network addressnecessary to establish a connection to the CRS 10.

The TSM further includes an Application Programming Interface (API)allowing contact management applications and plug-ins to access the CRS10 through the established session. The TSM includes functionality toaccept requests received through the API from a contact managementapplication, and provides common functions described herein. The use ofa TSM simplifies the development of contact management applications andassociated application plug-ins and reduces the need to developredundant functionality when numerous applications are supported for thesame operating system.

In one embodiment, an email application may be further adapted to parseincoming email messages using a common protocol such as POP 3 to searchfor serial numbers 22 attached to or included in an email. If the emailapplication locates a serial number 22, it may determine via across-reference file 554 (FIG. 12) if the application already hasrequested the serial number 22. If the application hasn't requested theserial number 22, the application may present a user interface dialogbox offering to make a request, and the user may make the request orclose the dialog box without making a request. If a contact serialnumber is not found in an incoming email, the email application mayalternatively issue a search request to the CRS 10 using otheridentified criteria, such as the sender's email address or contactinformation identified by parsing the incoming email.

Referring back to FIG. 2 b and FIG. 5, in one aspect of the presentinvention, wireless network devices are adapted to select, send andreceive serial numbers using infrared or radio waves. In one embodiment,User A and User B, each with their own wireless network devices, arewithin proximity of each other. User A selects one of his/her serialnumbers for transmission to User B and invokes the transmission process.The wireless network device encodes the serial number such that thereceiving wireless device may decode it and identify the serial numberas belonging to the service (e.g., incorporated URN syntax, as describedherein). User B's network device may present User B with the option ofaccepting or rejecting the transmission. If User B accepts thetransmission, User B's network device receives and decodes thetransmitted message. The wireless network device may then request theassociated contact record from the CRS 10. In one embodiment, thetransmission also includes an approval password or pin so that User B'srequest does not require further approval from User A.

In another embodiment of the present invention, a network device, suchas a public switched telephone network (PSTN) landline telephone usingSignaling System Seven (SS7) or similar protocol, is adapted to transmita request for contact information to the CRS 10 and receive a responsecontaining the requested contact information or other messages using SS7or a similar protocol. In one embodiment, a telephone network switchthat supports SS7 is adapted to receive a request from a PSTN landlinetelephone and forward the request to the CRS 10. The telephone networkswitch is also adapted to receive a response from the CRS 10 and forwardthe response to the PSTN landline telephone that made the request. TheCRS 10 is adapted to receive requests and transmit responses using SS7.In an alternate embodiment, the network switch is adapted to convert theSS7 request to a network protocol supported by the contact registryserver 10 (e.g., TCP/IP, HTTP).

Referring to FIG. 16, an alternate approach to utilizing a protocol suchas SS7 over a PSTN network involves adapting a telephone capable of PSTN(via SS7), Internet (TCP/IP, VoIP, etc), or Wireless (802.11, Bluetooth,etc.) network communication capability to transmit a request for contactinformation to the CRS 10 and receive a response containing therequested contact information or other messages using the phone'sinternet communications capability. In one embodiment, implementationleverages the Digital Enhanced Cordless Telecommunication (DECT)protocol for cordless phones. This approach may be more cost-effectiveand time-efficient compared to making modifications to PSTN networks.

In another embodiment of the present invention, the CRS 10 is adapted toreceive and transmit Short Message Service (SMS) communications. Arequest for a contact record including at least the unique serial number22 may be transmitted from an SMS-enabled device, such as mobile phone,to the CRS 10. The CRS 10 includes logic to parse the SMS request,retrieve the contact record corresponding to the received serial number,and transmit an SMS message including the requested contact informationin reply. The requested contact information may be transmitted as avCard, unformatted text, or other predetermined format. In this manner,an SMS-enabled mobile device may be used to request and receive contactinformation from the contact registry server 10 without requiringmodification of the software on the mobile device. Searches, searchresponses, and approval messages may be facilitated in a similar manner.SMS and vCard technologies are supported on most wireless devicesworldwide, which would further reduce barriers to adoption of thepresent embodiment. Other communication protocols supporting thereceiving and transmission of text messages over a network may beimplemented in a similar manner.

Referring to FIG. 20, in one embodiment a web page 1000 contains abanner advertisement 1001, which provides the advertiser's serial number22 as a clickable region 1002 that User A may click to receive theadvertiser's contact information. Implementation methods may use ahyperlink, Adobe Flash, image map or other technologies to submit asearch request or contact request to the CRS 10, and receive a vCard,search result or contact reply respectively. In another embodiment,clicking on the serial number hyperlink presents a dialog box or webpage enabling User A to select from a list of User A's serial numbersand provide other information requested by the advertiser.

In another embodiment, an advertisement 1001 on a web page 1000 orotherwise in a computer display may provide a serial number input field1003 and a submit button 1004, enabling the person viewing theadvertisement to provide a serial number 22 corresponding to theircontact information to the advertiser. In this embodiment, theadvertising vendor may collect a serial number 22 from a prospectivecustomer and request contact information via the serial number 22 fromthe CRS 10. The advertisement 1001 may also contain an approval PINinput field 1005 so that the advertiser is automatically approved toreceive the submitted serial number 22. Submission of the information tothe advertiser may be encrypted. In one embodiment, a request by anadvertiser for User A's serial number from the CRS 10 always requiresUser A's approval.

In another embodiment, the advertiser utilizes a Customer RelationshipManagement (CRM) system or Sales Force Automation (SFA) system adaptedfor communication with the CRS 10. The CRM or SFA system is furtheradapted to receive a serial number 22 submitted by a banneradvertisement 1001, and immediately generate a search request or acontact request to receive contact information associated to thesubmitted serial number 22. The CRS 10 may also be adapted with aparticular service level, which requires an advertiser or vendorutilizing a CRM or SFA adapted for communication with the CRS 10 tosubmit requests with an approval PIN or alternatively to require theapproval of the user associated with the serial number beforedisseminating contact information to prevent vendors, advertisers andothers from abusing a user's privacy. Prospective customers may beunwilling to enter complete information due to data entry effort orother concerns, thus, submitting a serial number 22 mitigates data entryeffort. An advertiser or other vendor may use contact informationreceived from the CRS 10 for lead generation purposes, or to contact theprospective customer to provide product or service literature, pricequotes, special offers or other information. Further, data entry andmaintaining accurate and up-to-date information are significant issuesfor users of CRM or SFA systems. Referring back to FIG. 2 e, at step118, approval criteria may involve a monetary payment by the advertiser.In another embodiment, approval criteria may involve the advertiserproviding the prospective customer with another form of consideration,such as a coupon.

In one embodiment, the CRS 10 contains logic for benefits indicators 359(FIG. 8 c) that presents the labor savings associated with the use ofthe system. An exemplary embodiment finds the sum of charactersincorporated into a contact record, and divides the sum by the number ofcharacters in the serial number 22. The CRS 10 or a network devicepresents the quotient to the user to indicate the estimated laborsavings users will realize when requesting the serial number as comparedto manual data entry. In one scenario, the CRS 10 computes this quotientfor each request to account for benefit variations due to theapplication of a data mask that selectively restricts the disseminationof certain attributes within a contact record as described herein. Inanother embodiment, the CRS 10 compares the foregoing quotient with aminimum threshold. If the quotient falls below the threshold, the CRS 10or a network device provides a message to the user indicating thatadding additional data to the contact record will save other users dataentry effort.

In another embodiment, the CRS 10 multiplies this quotient by the numberof requests for a particular serial number 22, and presents the productto the user to indicate the labor savings multiple requesters haveenjoyed collectively. In another embodiment, the CRS 10 periodicallysums the foregoing product of all serial numbers in the system toprovide the general public with an estimate of the cumulative laborsavings delivered by the system. Similarly, the CRS 10 may find the sumof quotients associated to the requests made by a user. The CRS 10 maypresent the labor savings in a user interface, or may send email reportsto the user on a periodic basis. Users who are aware of the savings mayuse the service more frequently.

In a further embodiment, the CRS 10 logic of the benefits indicators 359(FIG. 8 c) maps each attribute or group of attributes in a contactrecord to one or more text messages that indicate the benefits users mayaccrue when receiving the contact information associated to thoseattributes. The CRS 10 benefits indicators 359 (FIG. 8 c) also detectsempty contact record attributes, and presents the corresponding textmessage to the user if an attribute is empty. Users may be inclined toforego data entry if they do not understand the benefits accrued toothers (e.g., a record without an address is not useful for GlobalPositioning System (GPS) or mapping systems).

In one embodiment, use of certain contact management services, such as arequest for contact information, is provided to users without charging afee for the service. Providing services for free may be desirablebecause it promotes rapid and widespread adoption of the contactmanagement services. The contact registry service provider may collectrevenue through the placement of targeted advertisements (including themethods described herein and depicted in FIG. 20) in messages and webpages (e.g., banner ads) transmitted to User B in response to searchesfor serial numbers, requests for contact records, or other servicerequests, such as contact record updates. The contact managementprovider may collect additional revenue by offering premium services ona pay-per-use or subscription basis.

In one embodiment of the present invention, the CRS 10 reserves asequence of characters in a serial number 22 for the benefit of a userpaying a premium, or for the benefit of a particular organization orgroup. In one embodiment, the beginning character of a serial number upto a terminating character such as a period (.) may indicate a domain.Within this domain, the CRS 10 may reserve one or more charactersequences for a particular group. Exemplary embodiments of reservedkeywords include company names or stock ticker symbols. In oneembodiment, a registered user is only able to generate a serial number22 with a reserved sequence of keywords if the registered user's accountemail is confirmed with a particular domain name.

There may be many advantages associated with embodiments of the presentinvention. For example, in an embodiment, as discussed previously, acontact record is stored in a centralized database 18, and includes aunique, context-free serial number 22. A concise context-free serialnumber (e.g., not an email address associated with an email account or atelephone number associated with a residence, etc.) is useful forconveyance, contact information requests, creating a request log and arequestee log, and creating a cross-reference 554 (FIG. 12) between thecontact record stored in the data storage 18 and a database index of thenetwork device 32's contact management application.

Unlike a context-driven ID such as an email address or telephone number,or an ID that contains a network address or routing information, a userdoes not typically need to change the context-independent serial numberover time, avoiding a break in cross-reference links that would oftenoccur (e.g., when a person changes jobs and thus email addresses andtelephone numbers). In this manner, the context-independent serialnumber is associated with a trademark making it more easily conveyed.Using alphanumeric characters for the serial number makes it possible toissue short, personalized serial numbers amenable to user input thatidentify an extensive address space. By contrast, a conventional contactrecord may have over 100 characters, each of which requires entry undera manual input system.

An embodiment also makes it possible retrieve updates and to synchronizemany different types of devices and applications quickly, allowing auser to maintain consistent, up-to-date contact information across manydifferent network devices.

In continuing with the description of the contact registry server (CRS)10 of the present invention, in an embodiment, as shown in FIGS. 8 a-8c, the CRS 10 includes a network interface 302 to facilitatecommunications with network devices 30, 32, a processor 304, and aprogram memory 306 that includes logic for instructing the processor 304to facilitate the creation, storage, maintenance and retrieval ofcontact information in a data storage 18.

The program memory 306 of the exemplary embodiment includes a databaseserver 310 and a web application server 320.

The database server 310 includes a series of data structures 400 (FIG. 9a-9 b) which the database server 310 may use for storing data in thedata storage 18. The data structures 400 include a User ID table 402 forstoring information about registered users, including a User ID and userinformation. In one embodiment, user information includes an accountpassword and billing information, and may include additional data usedby the CRS 10. A second table 404 maps serial numbers to user IDs,allowing the system to track the user associated with each contactrecord, and allowing a single user to maintain contact information undermultiple serial numbers. For example, as discussed previously, a singleuser may have a plurality of contact records to accommodate multiplelanguages (e.g., English, French or Japanese), countries and uses (e.g.,business and personal). A contact record table 406 stores user contactinformation and an associated serial number. User contact informationmay include name, title, address, telephone numbers, email address,company name, web site, and other information. A user-defined fieldtable 410 stores user-defined fields-enabling a user to add fields thatare not part of the contact record 406. A group table 408 stores a groupserial number and a series of serial numbers associated to individualcontact records 406. A role-based serial number table 414 stores a roleserial number, a role description and one serial number associated to anindividual contact record 406. The SN/UID table 404 may also be used tolink the group table or the role-based serial number table to the userID. A namespace map table 412 stores the namespace, network address, andauthentication credentials for the CRS of other service providersoffering the same service. An offer table 416 stores contact recordoffers made by one user to another user. A request log table 418 storescontact requests made by network devices. A requestee log table 420stores the user IDs of the user who owns a contact record, the user IDof the requesting user, the requested serial number, and the approvalstatus among other attributes. When User A updates a contact record, aninternal update table 422 stores update notifications for User B, whopreviously requested the serial number. An approval record 424 storesthe approval status and reply method of requests that require approval.The exemplary embodiment describes the various processes andimplementation with various database technologies may lead to variousconfigurations.

The web application server 320 includes a registration manager 330 forhandling user registration, an authentication manager 340 forauthenticating users and devices accessing the CRS 10, a contact recordmanager 350 for handling the creation, storage and updating of contactinformation, a billing manager 361 for charging users, a contact requesthandler 370 for delivering contact information to requesting networkdevices, a group manager 380 for handling group creation and management,and a role manager 390 for handling role creation and management.

The registration manager 330 includes processes for creating a new user332, creating a plurality of new users through a batch process 334,verifying users 335, changing/retrieving a password 336 and deletingusers 338. In one embodiment, these processes may be invoked by a userof a network device 30 through a web page interface or via the interfaceof a contact management application.

In an alternate embodiment, the “new user” batch process 334 invokes thecontact record manager 350 to create a plurality of contact recordssimultaneously. The batch process includes receiving, at the CRS 10, abatch of input data consisting of contact information for a plurality ofusers. The batch process creates new users and generates batch outputdata, including the user ID, the temporary password, and the serialnumber 22, as well as information from the batch of input data (e.g., anemail address or a mailing address) that will assist in disseminatingregistration data to the newly registered users.

The contact record manager 350 generates the serial number 353 for eachcontact record and creates a new record to link the user ID and thecontact record's serial number 404 (FIG. 9 a). Invalid batch data can belogged and returned to the requestor in a report. The batch input andoutput data could come from a file, a database, a network, a directoryservice (e.g., Lightweight Directory Access Protocol (LDAP) or ActiveDirectory) or other source.

Once a user completes the registration process and changes the assignedtemporary password, the contact record may be published, which makes itpossible for network devices 32 to request the contact record. Next, theuser may set contact permissions 354 for the contact record, which makesit possible for the user to deliberately authorize or refuse eachrequest for the contact record, or to automatically approve or rejectrequests.

The contact permissions process 354 restricts access of third-partyusers and network devices to particular contact records. When a contactrecord is published, the contact information is available for retrievalby any user who enters the corresponding serial number 22. Through thepermissions feature 354 and the approval processor 374, a user maymanually approve each request for the user's contact information,automatically approve each request, or establish rule-based conditionsfor approving access to the contact data. For example, the user can denythe provision of contact information to anonymous requestors. Referringback to FIG. 1, when User B requests User A's contact record, the systemcan generate a response to User A indicating that it is awaitingapproval from User A to release the requested information to User B.This would spawn follow-up requests for the record (if approved), arefusal message (if the request is rejected), or a “still waiting”message.

The delete users process 338 includes both single delete and batchdelete capabilities. In one embodiment, a large entity such as a mobiletelephone provider or Internet Service Provider (ISP) offers access tothe CRS 10 as a value-added service bundled with other offerings. Thebatch delete would be used by large entities when access to the systemschanges on a regular basis and may be part of standard integration ofthe contact registry service to the large entity. In another embodiment,an individual user deletes his or her registration, which is consistentwith the EU Directive on Data Privacy or HIPAA that requires that asubject has the right to request the removal of his or her informationfrom a third party server.

In another embodiment, an “existing user” batch process invokes thecontact record manager 350 to update a plurality of contact recordssimultaneously. The batch process includes receiving, at the CRS 10, abatch of input data consisting of contact information for a plurality ofusers. The batch process provides a user ID, one or more serial numbersand updated information for each serial number. Using the user ID andserial numbers, the batch process selectively retrieves a contact recordassociated to a serial number, then, updates the contact record withupdated data and saves the record. Batch processes for registering users(and deleting registrations), and creating, updating and deletingcontact records' may reduce the effort associated with updating aplurality of users simultaneously, such as the employees of a largecorporation or the users of a third party service such as an InternetService Provider (ISP) or a wireless network carrier.

The contact record manager 350 includes program logic for creating a newcontact 351, managing contacts 352, generating serial numbers 353, andmanaging contact permissions 354 such as making a contact recordavailable for search and request, and setting request approval criteria.In one embodiment, the logic for generating serial numbers 353 includesa pattern recognition algorithm to filter out serial numbers includingoffensive or otherwise undesirable sequences of digits. A contact eventmanager 355 tracks contact record manager activity 350 and may beconfigured to invoke additional event-driven processes. A search indexmanager 356 parses a contact record and transforms it into a formatsuitable for a search engine. A content verification 357 functionenables the contact record manager to invoke third party services toverify the content of a contact record (e.g., an address verificationsystem). A signature generator 358 enables the contact record manager tosign digital works using the contents of a digital work, a user's serialnumber, and a private key such as a password to generate a hash code(e.g., MD5). A benefits indicator function 359 provides alerts andreports to users to indicate the benefits of using a serial number andincluding additional data in contact information within contact records.The user provides contact information through the contact record manager350 which stores the contact information in the data storage 18 via thedatabase server 310. Personal contact information may be input andupdated through the user interface of a network device 30, including aweb page interface.

The contact request handler 370 includes device registration 371 foruniquely identifying each network device 30, 32 that communicates withthe CRS 10; a search processor 372 for processing search requests andgenerating search results (FIG. 6 a-6 c); a request processor 373 forprocessing contact request and replies (FIG. 7 a-7 c), generatingrequest logs 418 and requestee logs 420, and invoking the requestprocessor 373 as needed; an approval processor 374 for managing theapproval process of a request, including notifying users, generatingapproval records 424 (FIG. 9 b), and providing replies; a digestgenerator 375 for signing contact replies; a namespace redirect 376 forlooking up different namespaces 412 (FIG. 9 a) and rerouting requestsfor records located within different servers; and a data mask manager378 for selectively restricting access contact records on an attributelevel.

An exemplary network device 500 is further illustrated in FIG. 11 a. Thenetwork device 500 may be any device adapted to communicate with the CRS10, such as a personal computer, a personal digital assistant (PDA), awireless phone, a VoIP phone, a landline phone (e.g., using SS7protocol), or another type of network-enabled device. The network device500 includes a network interface 502, providing access to the CRS 10through the network, a program memory 504 and processor 506 forcontrolling the network device 500, a data storage 508 and a userinput/output mechanism 510, such as a display and keyboard.

Referring to FIGS. 11 a and 11 b, the program memory 504 includes acontact management application 520 which includes, or is enhanced with,registry information 522 and login information 524, which enable thecontact management application 520 to access the CRS 10. A serial numbervalidation function 526 checks the validity of a serial number formatentered by a user. In the exemplary embodiment, the serial numbervalidation function 526 verifies that the serial number entered by theuser is a 9-digit alphanumeric string and that the error detection codeis accurate. A contact manager function 528 provides an interfaceallowing a user to add, edit, delete and view a plurality of contacts. Acontact request manager 530 enables a user to request contact recordsfrom the CRS 10. The contact request manager 530 retrieves the networkaddress of the CRS 10 from the registry information 522, generates arequest message, and transmits the message to the CRS 10 via the networkdevice's network interface 502, the network 20, and the CRS 10's networkinterface 302. A contact cross reference function 532 maintains a crossreference table mapping the serial numbers of retrieved contact recordsto the contacts stored by the network device.

In an alternate embodiment, the program memory 504 includes one or morenetwork-enabled applications. For example, a graphics designapplication, such as Adobe Illustrator or Adobe InDesign, may includeenhancements in the form of a plug-in allowing the application toreceive a serial number, contact the CRS 10, and retrieve associatedcontact information. Through a graphics design application, the user maycreate a graphic that includes graphic variables. Entering the serialnumber into the menu for the application plug-in will cause the graphicvariables to be set in accordance with the current associated contactinformation. An employer could use this feature to manage and printbusiness cards, or a printing company might operate as a retail point ofsale for the service. When the user updates data, the graphic variableswill update automatically.

In another embodiment, the serial numbers of the exemplary embodimentmay also be used to aid the completion of online forms. For example,User A may register with a plurality of web sites, with each web sitehaving its own registration screen seeking personal information fromUser A. Affiliated web sites may include a serial number input fieldallowing User A to complete the contact information aspects of the formmerely by entering his serial number. The web site benefits by ensuringit maintains current customer data, and enticing new users due to thesimplified registration process. In some applications, the serial numbermay be used for user authentication allowing the user to protect his/heremail address (and limit spam) and reduce the risk of providing creditcard information over the Internet (e.g., ID theft). Further, thecontact registry server tracks who has access to the contact registryinformation, allowing the user to track web sites to which the user is amember and allows the commercial web sites to maintain current contactinformation for the user.

The serial numbers of the exemplary embodiment may be used anywhere thatcontact information is requested, including in commercial transactions.For example, User A may contact a customer service call center, ordesire to facilitate a commercial transaction such as purchasingmerchandise, renting a car, registering for a hotel room, or booking anairline flight. When contact information is requested through aweb-based contact request screen, a field for entry of a contactregistry serial number simplifies the contact information requestprocess, allowing the remaining contact fields to be populatedautomatically with corresponding contact information received from thecontact registry server. A customer service representative, whether viatelephone or in person, may input a serial number from a user into anapplication adapted for communication with the contact registry server10 to retrieve all required contact information from the contactregistry server in lieu of manual data entry. Organizations benefitthrough the use of the serial number by reducing the amount of dataentry required to acquire demographic information, including reducingthe risk of repetitive stress injuries. Organizations also benefit byensuring accurate data entry, and by receiving periodic updates to thecontact information as customer contact information changes.

In another embodiment of the present invention, a commercial applicationsuitable for creating electronic forms, such as Adobe Acrobat, may beadapted for communication with the CRS 10 to retrieve contactinformation from the CRS and populate the fields of the electronic form.In another example, a serial number may be embedded into a PDF, allowingthe PDF to be updated as corresponding contact information changes. Thisembodiment may be used with employment forms, tax forms, loanapplications, health care forms, and other forms that utilize softwaresuitable for creating or editing forms, such as Adobe Acrobat.

Serial numbers may also be used to facilitate mapping, navigation andGPS-related services. In one embodiment, a user seeking directionsbetween two addresses can enter the serial number for the sourcelocation and the serial number for the destination location (in contrastto entering two complete addresses) into a compatible internet mappingor navigation system to retrieve the desired directions. Up-to-datecontact information can be provided to any Internet-enabled device,ensuring that the two contact addresses are current. Many wirelessdevices are GPS and Internet enabled allowing users to request real timeand location-specific information for the wireless device. For example,a wireless device can determine its current GPS location and identifylocal services such as the closest movie theater and current movietimes. Contact information for such establishments may include anassociated contact serial number, allowing the establishment's contactinformation be easily added to a user's contact address book and theuser to receive contact information updates. In one embodiment, anapplication on the GPS/Internet-enabled device is adapted to displayserial numbers along with establishment contact information, and add theserial number to the user's contact management application upon userrequest. In another embodiment, the contact registry server includes areverse lookup function that retrieves a current GPS location oraddress, and returns the identities, contact information and serialnumbers of the closest publicly available contacts satisfyinguser-selected criteria (e.g., restaurants or movie theaters).

The contact registry server and compatible network applications mayfurther include information retention services that are adaptable to anindividual's or entity's document retention requirements. When a contactmanagement application requests an update from the contact registryserver and the contact registry server provides an updated contactrecord, the original contact information will be lost unless saved bythe requesting application prior to the update. This poses a potentialproblem to a corporation having a document retention policy thatrequires such information to be retained for a certain period of time,or to an entity that is involved in public policy or litigation and maybe required to preserve electronic information. In one embodiment, acontact request history is maintained by the service module inaccordance with user preferences that may include identification ofrecords to store in the history, corresponding data fields that shouldbe stored, and the specification of a “delete after” date (e.g., deleteafter 5 years).

In another embodiment, the contact information includes substantivecontent for use by a network-enabled application. For example, a contactrecord may include a graphic or logo, audio data, or specify a certainfont style associated with the contact information that will control thelook and feel of material printed through the network-enabledapplication.

In another embodiment, the contact registry server is provided as anadd-on service to the services offered by cellular networks or internetservice providers for a nominal fee per subscriber. Revenue may begenerated by charging users for information retrieval using suchservices.

In one embodiment, third party web sites and applications are adaptedfor use with the present invention using composite application methodspopularly known as “Web 2.0” or “mashup.” Technologies such asAsynchronous JavaScript and XML (AJAX), JavaScript Object Notation(JSON) and the Document Object Model (DOM) facilitate the incorporationof data and functionality available from the CRS 10 into the web userinterfaces of third party applications.

Referring to FIG. 15 a, a Third Party Application (TPA) 620 resides in athird party application server 600, which serves as the applicationinterface to a client browser 650 and accepts requests (and posts) fromthe browser 650 via a network 20. The third party server 600 may providethe browser 650 with Hypertext Markup Language (HTML) data 602 to rendera user interface, Extensible Markup Language (XML) data 604 to provideapplication data, Cascading Style Sheet (CSS) data 606 to aid inrendering the HTML and data, and JavaScript data 608 to manipulate andgovern the behavior of the user interface (among other uses). Thebrowser 650 may process and render the data accordingly using theDocument Object Model (DOM) and a JavaScript interpreter among othertechnologies.

The TPA 620 also has an Application Programming Interface (API) 610 thatenables other applications to interact with the TPA 620. Similarly, theCRS 10 has an API 60 that may process requests from the third partyapplication servers 600, browsers 650, or other network devices 30, 32(FIG. 1).

In one embodiment, the TPA 620 is able to retrieve HTML data 52, XMLdata 54, CSS data 56, and JavaScript data 58 from the CRS 10. Usingcomposite application techniques, the TPA 620 is adapted to serve webpages containing HTML (52 and 602), XML (54 and 604), CSS (56 and 606)and JavaScript (58 and 608) such that it is able to presentfunctionality from the TPA 620 and the CRS 10 in a single web page. TheTPA 620 is further adapted to receive requests intended for the CRS 10from the browser 650 via the network 20, then, the TPA may redirectrequests to the CRS 10 via the API 60, and finally, receive responsesfrom the CRS 10, which are sent to the browser 650.

Referring to FIGS. 15 a-15 b, in one embodiment, the TPA 620 is able toserve HTML data 602 containing an XML data map 672, and contactinformation formatted in XML 674. Using various script programmingtechniques, a script is able to detect the presence of a data element byits ID within the HTML 602 (e.g., “company”), then, determine if acorresponding target ID exists within the data map 672. If acorresponding target ID exists in the data map 672, the script retrievesa source ID. Finally, the script retrieves a value from contactinformation 674 and resets the value of the target ID within the HTMLdata 602. Through these and other methods, the CRS 10 and third partyapplications are capable of presenting CRS 10 functionality to thirdparty web applications, and providing third party applications withcontact information from the CRS 10.

In one embodiment, a web page for a TPA 620 is adapted to accept ausername or serial number (in lieu of the username) and password, whichis sent to the CRS 10 to authenticate the user of the TPA 620 with theCRS 10. In one embodiment, the CRS 10 responds with an access token,which authenticates the user in subsequent requests to the CRS 10 untilthe access token expires or the user logs out.

The third party application is further adapted to retrieve User A'spersonal serial numbers and the corresponding contact information. UserA may create, edit or delete his or her serial numbers via the TPA'suser interface. In one embodiment, the TPA 620 is adapted to presentUser A's serial numbers to other users of the TPA.

In one embodiment, a TPA 620 user interface is adapted to accept serialnumbers, send requests to the CRS 10 and receive responses from the CRS10. In an exemplary embodiment, User B enters User A's serial numberinto the user interface of the TPA 620 and receives a contact recordfrom the CRS 10, which is rendered in the user interface of the TPA 620.In another embodiment, User B enters search criteria and receives a listof serial numbers which match the search criteria in a search result,and User B may further request a specific serial number (a contactrequest) from among the search results and receive a contact reply.

In another aspect of the present invention, the CRS 10 contains a listof contact records User B requested from other users. A TPA 620 isadapted to retrieve User B's list of contact records from the CRS 10 andpresent the list of contacts to User B within the user interface of theTPA 620.

In another aspect of the present invention, the CRS 10 contains a listof requests for User A's contact records. A TPA 620 is adapted toretrieve the pending requests for User A's contact records from the CRS10 and present the list of requests to User A within the user interfaceof the TPA 620. User A may approve or decline each request for a contactrecord within the user interface of the TPA 620, and the TPA 620 willupdate the CRS 10 accordingly.

In another embodiment, User A may offer a serial number(s) to User B viathe user interface of the TPA 620, and User B may accept or decline theoffer. If User B accepts the offered serial number, the TPA 620 requeststhe contact record from the CRS 10.

In another aspect of the present invention, a TPA 620 with e-commercecapability is adapted to present CRS functionality that enables User Ato register with the CRS 10, create a serial number 22 and contactrecord, and if necessary to transmit the serial number and contactrecord back to the TPA 620 for further use. In one embodiment, the TPA620 provides the CRS 10 with authentication credentials uniquelyidentifying the TPA 620, and, the CRS 10 contains logic to record UserA's activity. The CRS 10 is able to analyze User A's activity for futurebilling to the owner of the TPA 620. In another embodiment, the TPA 620is adapted to present the CRS 10's credit card billing fields, and totransmit billing information from the TPA 620 to the CRS 10 securely.These methods enable third party e-commerce applications to sell CRS 10services to their customers.

Exemplary embodiments of the present invention may include integratingCRS 10 functionality with third party applications such as online emailapplications, social networks, online web meeting applications, mappingand driving direction sites, shipping sites, retail web sites, orauction sites among others. People utilize or otherwise exchange contactinformation when using these types of third party applications, andpeople may benefit substantially from the foregoing exemplaryembodiments.

Various implementation techniques may include “toolbar” extensions toweb browsers, portlets (e.g., JSR-168) within web pages, or fields andpage areas “mashed up” into the user interface of the third partyapplication. Other implementations may use XML derivations such asSimple Object Access Protocol (SOAP) and web services to facilitateinteraction with third party applications.

In one embodiment, a web browser is adapted to retrieve each contactrecord User B requested, and to create a bookmark in User B's webbrowser using the URL attribute of the contact record. The “requestreplication” method of synchronization described herein may createuseful records other than contact information records in a contactmanagement application.

In an alternate embodiment, an online meeting application (e.g., WebEx)is adapted to authenticate a first meeting attendee with the CRS 10,retrieve the first attendee's serial number(s), and present the serialnumber to second attendees. These other attendees may select the firstattendee's serial number and thereby request the contact information ofthe first attendee. If the requesting attendee is authenticated with theCRS 10, the request is recorded in the CRS 10 along with the attendee'sauthentication credentials automatically. If the attendee is notauthenticated, the CRS 10 may prompt the attendee to provide a name,email address and note via the third party user interface to facilitateapproval and update processes.

In one embodiment, a third party application such as an e-commerce site,an auction site, a mapping site, or a shipping site requires addressinformation such as origination and destination addresses. The TPA 620is adapted to enable User A to select a contact record from the list ofcontacts and to populate similar data fields presented in the userinterface of the third party application. In one embodiment, the thirdparty application is adapted to use drag-and-drop technology.“Auto-fill” technologies could thereby be augmented to retrieve contactinformation from the CRS 10 and automatically enter contact informationfor persons other than User A (e.g., entering a third person'sinformation in a web-based mapping application, or in a mailing addressfield for the purposes of gift giving, drop ship, driving direction,etc.).

Referring to FIG. 17, in one embodiment, User B operates a plurality ofnetwork devices ND_1, ND_2 and ND_3, such as a personal computer, mobilephone and PDA device. In operation, User B enters a serial number in afirst network device ND_1, which transmits a contact request message toa contact registry server (CRS) 650 through a network 652. The CRS 650returns a contact reply to ND_1 including the requested contactinformation. The CRS 650 also creates an entry in a request log 654 inthe database (DB) 656, logging the time the contact request from ND_1was processed. ND_1 receives the requested contact information from theCRS 650 and stores the received contact information locally in a memoryor other data storage associated with the ND_1.

The request log 654 tracks contact information requests and may includea user ID, a device ID, a request type, the requested serial number, anda timestamp for the request. The user ID uniquely identifies therequesting user and may include one of the user's personal serialnumbers assigned by the CRS 650, a login name or other identifier. Thedevice ID uniquely identifies the requesting network device, and in oneembodiment a unique identifier is provided in each copy of the networkdevice software before it is deployed on a network device. The CRS 650may associate a request log with one of the requesting user's categorieswhen the request log includes the serial number for the requestinguser's contact. In this manner, a user with more than one serial number,for example, a work serial number and a personal serial number, maymanage the synchronization of separate contact lists. In an alternateembodiment, the request may contain a category attribute that enablesthe user to synchronize only a subset of the contacts requested byvarious devices (e.g., only synchronize contacts in the “work”category). In another embodiment, the request may contain a list ofnetwork device identifiers to synchronize only a subset of the contactsrequested by various devices (e.g., only certain devices shouldsynchronize the requested contact). In another approach, the networkdevice software requests a unique identifier from the CRS 650.Alternatively, the MAC address associated with the network devicehardware may be used. Identifying each device facilitates thesynchronization of contact records across multiple devices. For example,if a person requests a contact record with one device, another networkdevice can request the same record without additional user effort.

The request type includes a code identifying whether the receivedrequest is for new contact information, an update to existing contactinformation, a request to delete contact information associated withUser B or other type of request. When User B requests User A's serialnumber, the contact information is received and may be inserted as a newrecord into User B's contact management database. User B may laterre-request User A's serial number, in which case the contact informationis received, the corresponding contact record is located, and the storedcontact information is updated with any changes. User B may also issue arequest to delete User A's contact information, which causes the contactinformation record to be deleted from the contact management database.Each of these requests corresponds to database functions that may beimplemented in this manner.

Initially, the requested contact information (stored on ND_1) is notstored on network devices ND_2 and ND_3. User B may separately enter theserial number into the contact management applications of ND_2 and ND_3to retrieve the contact information from the CRS 650. In one embodiment,the network devices ND_1, ND_2 and ND_3 include a synchronizationprocess that is automatically invoked when the respective network devicecontacts the CRS 650 with a contact request. The network devices mayalso be configured to periodically (e.g., daily, weekly, monthly, etc.)invoke the synchronization process to regularly check for updates.Further, it is contemplated that a user may manually invoke thesynchronization process through the contact management application whendesired.

The request log 654 enables User B to initiate a synchronization requestto the contact registry server 650 from a network device to download newcontact information, remove deleted contact information, and updatemodified contact information. In this manner, User B is not required toreenter contact serial numbers into each device. In one embodiment, thelog's timestamp is used to limit synchronization to records that havebeen added, updated, or deleted since the device's last synchronizationrequest. The network device may be identified through a device ID andthe request log stores the timestamp of the last synchronization foreach device ID.

Referring to FIGS. 18 & 19, the synchronization process will bedescribed. When the synchronization process is invoked, asynchronization request message, including the user ID and device ID, istransmitted from the ND_2 to the CRS 650. In one embodiment, the requestmessage may include a serial number associated to a contact of therequesting user or a category. The CRS 650 receives the request in step700 and queries the Request Log 654 to find the last time that ND_2contacted the CRS 650 in step 702. In step 704, the CRS 650 retrievesall the request types and serial numbers from the request log entriesassociated with requests by User B subsequent to ND_2's lastcommunication with the CRS 650, which may be measured by a timestampfield in each entry or some other serial field. In step 706, the CRS 650retrieves the contact information for each serial number (not needed forrequest type “delete”) and generates contact reply messages to transmitthe contact information to ND_2 in step 708. In this case, since User Bentered User A's serial number in ND_1, there is a request log entry forUser A's serial number. When ND_2 transmits a synchronization request,it receives User A's serial number and contact information from the CSR650 in the reply. Finally, in step 710, the synchronization request fromND_2 is added to the Request Log 654, along with a current timestamp.

The network device ND_2 updates the contact information stored on ND_2in accordance with the received request type. In the exemplaryembodiment, a serial number/database record cross-reference tablefacilitates the update of contact records. An embodiment of an updateprocess with a cross-reference table will now be described withreference to FIG. 19. When User B enters a serial number into thecontact management application of a network device, a request istransmitted to the CRS 650, which returns associated contactinformation. A new contact record is created in the local contactinformation database and the received contact information is stored(step 800). When a new contact record is created, the contact managementapplication assigns a local record identifier (or database index), whichis stored as part of the record. In step 802, an entry in across-reference database 660 (FIG. 17) is added, mapping the localrecord identifier to the serial number associated with the contactinformation.

The cross reference table allows the contact management application toupdate contact records with information stored at the CRS 650. Forexample, a single contact record stored on ND_1 can be updated byquerying the cross-reference table for the associated local recordidentifier, identifying the associated contact serial number, andspecifying the contact serial number in an update request transmitted tothe CRS 650. In step 804, contact information is received from the CRS650, and the contact serial number is used to retrieve the local recordidentifier from the cross-reference table in step 806. Next, in step808, the contact record associated with that local record identifier isretrieved from the contact management application. The contact recordstored on the network device may then be updated with new information(or deleted as required).

The contact records are updated according to the received “request type”associated with the contact information. Request types include “newrecord,” “update” and “delete” (among other possible request types).When a network device ND_3 synchronizes its contact information with theCRS 650, a “delete” request from ND_1 will be invoked, and duringsynchronization the contact reply to ND_3 will have a “reply type” of“delete” and the associated serial number. The contact record associatedwith the received serial number is then deleted from the contactinformation database and the cross-reference database.

In one embodiment, when records are added and then subsequently deletedbefore synchronization can take place, program logic at the contactregistry server does not include the records in the replies to avoidunnecessary work by the network device. In another embodiment, thecontact registry server further includes an approval log so thatsynchronization requests do not require User B to approve subsequentrequests for every single network device that User A uses. For example,if User A has the serial number of User B, User B may have the option todisallow subsequent requests or updates from User A by removing User Afrom the Requestee log until User B approves the request subsequently.

As discussed previously, an exemplary contact reply data structure isillustrated in FIGS. 7 b and 7 c. A contact reply message includes areply type, serial number and contact information fields. A plurality ofupdates may occur between sessions and the reply message may have morethan one contact reply. To accommodate multiple contacts in a replymessage, a contact reply container includes at least one contact replymessage and facilitates the transmission of reply messages as a batch. Asingle contact reply container may include reply messages havingdifferent types, such as a contact record or a message to the user(e.g., “awaiting approval”).

In one embodiment, when sending a reply message to the network device,the message is encrypted in a common encryption protocol such as MD-5,using the user's User ID as a public key and password as a private key.Using encryption for messaging and storage makes it more difficult forunauthorized users of the contact registry server to gain access toinformation by eavesdropping, “sniffing” or “spoofing” packet-switchednetwork connections.

Further with respect to encryption, the data that is associated with acontact record that is transmitted to a network device in response to arequest by the network device can also be encrypted. In this manner, thedata can be used by the network device of the recipient for contactingthe person associated with the contact record, however, the actualcontact data itself cannot be learned by the recipient because it isencrypted. This can provide utility because it allows the subject of thecontact record to provide the contact information to a recipient andallows the recipient to use the contact information, but yet, itprotects the privacy of the data for the subject person of the contactrecord because the data is encrypted, and thus, cannot be known, andperhaps be further transferred, by the recipient themself. In thisembodiment, a plug-in may be utilized with the recipient's networkdevice such that the plug-in is able to contact the subject with thedevice by decrypting the encrypted data.

Referring back to FIG. 17, in one embodiment a requestee log 658 is usedto track and control access to user records. When User B requests UserA's contact information, for example, a new record is added to therequestee log 658 that indicates that User B has User A's contactinformation. As illustrated, the “user's ID” is the serial number forUser A and serves as a primary key in the database, and the “requesteeserial number” is the serial number for User B. When User A makes achange to his or her contact record, the contact manager sends aninternal update to each user linked to User A through the requestee log.The internal updates may be maintained in a database table 422 such asthat illustrated in FIG. 9 b. Where an internal update table is used,records are retrieved as part of the user's synchronization andconverted to an entry in the request log to be downloaded the next timeUser B accesses the CRS 650.

In another embodiment, a new device (e.g., ND_4) registers with the CRS650. Since it is a new device, there are no previous requests, thus, thesynchronization process will retrieve all previously requested serialnumbers and populate the new device with contact records. In analternate embodiment, by specifying a new type of request such as“restore,” the CRS 650 may be adapted to override the timestamp of thelast synchronization for the device, and thereby retrieve all previouslyrequested serial numbers to update and repopulate the device. Thus, CRS650 may provide a means of backing up requests such that new devices, ordevices that have malfunctioned, may retrieve all contacts.

In one embodiment, the network device is adapted to ensure that the“request replication” method of synchronization does not conflict withtraditional methods of synchronization (e.g., the SyncML standard) thatmay operate concurrently. Prior to initiating a “request replication”synchronization request, the network device searches each contact recordin a contact management application that does not have a correspondingentry in the cross-reference record to determine if the record containsa serial number and/or other digest information. If the network devicefinds a record that contains information generated by the CRS 10 (e.g.,a serial number or digest), the network device may infer that the recordcorresponds to a record in the CRS 10. The network device may thencreate an entry in the cross-reference record to prevent thesynchronization process from creating a duplicate record.

In one embodiment, contact management application 520 (FIG. 11 b) on anetwork device is adapted to detect when User B accesses a contactrecord that has a corresponding entry in the cross-reference 554 (FIG.12). The cross-reference is further adapted to store an attributeindicating the last time and date when User B accessed the contactrecord, and the total number of times User B accessed the contactrecord. Each time User B accesses a contact record with a correspondingentry in the cross-reference, the contact management application 520resets the last accessed time and date and increments the total numberof times accessed in the cross-reference 554. The contact managementapplication 520 is further adapted to forward these attributes for eachcontact record in the cross-reference to the CRS 10 periodically. TheCRS 10 is adapted to enter the most recently accessed contact record atthe top of a list of recently accessed records for the network deviceand to summarize the number of times User B accessed a particularcontact record on a network device. The CRS 10 is further adapted tomerge each list for all devices associated to User B. The CRS may befurther adapted to store these ordinal rankings in request logs, or toautomatically categorize requested contacts according to an ordinalclassification such as “Most recently accessed” and “Top 10 Contacts.”The CRS and network devices may present or organize records and executefunctionality according to the most recent accessed record or howfrequently User B accesses particular contact records. For example, UserB may have hundreds of records and may access one record via an emailaddress book, which makes the accessed record appear in a “most recentlyaccessed” list in a cellular phone, GPS system, etc. Additionally, theordinal classification may occur irrespective of the type of device orcontact management application used to access the record (e.g., cellphone, email, IM, etc.).

In another embodiment, User B may utilize remote deletion functionalityin conjunction with ordinal rankings to remove all contacts in thecontact management application of a network device, and then usesynchronization functionality to populate the same contact managementapplication with a subset of contacts available to User B at the CRS 10using category attributes. In one embodiment, User B only wants “Top 10Contacts” on a network device. In another embodiment, User B only wantslocation-based contacts on a network device. This may be desirable sincenetwork devices may have limited capacity and performance, and contactrecords may have limited utility. For example, a person on a businesstrip may wish to have a contact management database containing only “Top10 Contacts,” “Most Recently Accessed” and location-based contacts fromthe locale of the business trip for more rapid retrieval of relevantcontact information.

In one embodiment of the present invention, User A creates a serialnumber 22 via the CRS 10 and inputs his or her contact information intothe corresponding record 406 (FIG. 9 a). The CRS 10 is further adaptedto enable User A to specify preferred methods 360 (FIG. 8 c) ofcontacting User A. The CRS 10 stores this information in the contactrecord and User A may update it on a regular basis. Preferred methodsmay include an ordinal list of preferences (e.g., email first, IMsecond, cellular phone third, etc.), rule-based preferences (e.g., donot call after 7:00 p.m.), or other methods such as presence detection(e.g., User A is logged into an Instant Message (IM) system, User A'sGPS system provides coordinates to the CRS 10 indicating physicalpresence at User A's office, etc.).

A request by User B's network device for User A's serial number andcontact record results in the dissemination User A's contact informationto User B's network device along with the preferred methods ofcontacting User A. The network device is adapted with a preferred methodmanager 536 (FIG. 11 b). When User B views User A's contact record, UserB's network device may present the preferred method for contacting UserA.

In one aspect of the present invention, User A's network devices areadapted to update User A's contact record 406 in the CRS 10 by providinginformation regarding User A's availability (e.g., User A's GPS systemindicates physical presence near User A's home or office, User A's cellphone is on, User A is logged in to an IM system, etc.). The networkdevice contains logic as a presence manager 534 (FIG. 11 b) to determineUser A's availability and notify the CRS 10. The CRS 10 contains logicas presence detector 379 (FIG. 8 c) to receive information from thenetwork device and update User A's contact record. User B's networkdevices may receive updates from the CRS 10.

In one embodiment, when User B attempts to contact User A by atext-based method (e.g., email, SMS, or IM), the network deviceretrieves the preferred method, and the address or network identifierfor the preferred contact method from the contact record. User B maythen send the text message to User A via that method.

In another embodiment, when User B attempts to contact User A byvoice-based methods (e.g., telephone, wireless phone, or VoIP) thenetwork device attempts to connect via preferred methods in an ordinalmanner (e.g., via VoIP first, via PSTN second, via cellular phonethird—where the ordinal preference reflects the increasing cost of eachmethod).

In one embodiment, User B attempts to contact User A via a text-basedmessage, and User A's preferred method for receiving a message isvoice-based. The text message is converted to speech via text-to-speechtechnology, and left as a voice mail message for User A.

In one embodiment, User B attempts to contact User A by voice-basedmethods, and user A prefers to receive text messages. User B may createa voice message that is converted to an audio file and sent to User Avia a preferred text method that is also capable of processing a voicefile (e.g., email or IM).

If User A specifies that a user such as User B may view User A's contactinformation, the network device may decrypt and present User A's contactinformation to User B. Alternatively, User A may completely precludeUser B from identifying User A's actual contact information. The networkdevice may store the requested record, which User B's network device mayaccess later, provided the stored copy of User A's contact record hasnot exceeded its expiration date/time. If User A's contact record hasexceeded its expiration date/time, User B's network device may requestan update from the CRS 10.

In another aspect of the present invention, User A may further specifyan expiration time/date for the record received by the network device.In this embodiment, User B's network device is adapted to receivecontact information from the CRS 10 and to initiate communications withUser A via that information. The network device may not present User A'scontact information to User B, so User B may not have actual knowledgeof User A's contact information. In this manner, some users will preferto withhold their actual information from recipients of their contactinformation record.

In an embodiment, the CRS 10 enables User A to create a proxy emailaddress and include it in his or her contact record along with User A'sactual email address. The CRS 10 is further adapted to configure anemail server to receive email messages at the proxy email address andforward received email messages to User A's actual email address. Thus,User A may keep his/her contact information completely private(indirectly available to User B), and simultaneously provide User B withthe most convenient method of contacting User A by the mere conveyanceof User A's serial number to User B, and User B's request for User A'sserial number.

An embodiment of the present invention involves disseminating Public KeyInfrastructure (PKI) keys (e.g., X.509). PKI involves generating twokeys: a public key for encrypting communications; and, a private key fordecrypting communications. A person may also use a private key todigitally “sign” a communication, and the public key may be used toauthenticate the “digital signature.” PKI technology is widely availablefor personal use, and is widely used by websites for Secure Socket Layer(SSL) encryption. Public keys are lengthy and cryptic; therefore, theyare not amenable to verbal, handwritten or printed conveyance, norsuitable for manual data entry. Conveying public keys via insecure emailor network connections or making them freely accessible on a publicserver enables an unintended recipient to encrypt communications via thepublic key, or to authenticate communications signed with the privatekey via the public key. To enhance security, people who use PKItechnology in their personal communications often change theirpublic/private key pairs frequently.

Using the process described herein to convey public keys in the samemanner as other contact information may provide at least the followingbenefits: a contact record may be searched and requested; a serialnumber 22 is easier to convey and enter when compared to a public key; auser may approve or reject a request for a contact record—therebyproviding a level of access control to a public key; the process oftransmitting the contact record (including the public key) may itself beencrypted—further preventing access to the public key by unauthorizedpersons; an update process enables a requester to receive updates topublic keys when the user who controls the contact record changes theprivate/public key pair; and through request-replication, multiplenetwork devices associated to the same user may receive access to thepublic key efficiently.

In one embodiment, the process of creating a record in step 104 includesa field for storing a public encryption key (e.g., using X.509cryptography) in the contact record. User A may convey the associatedserial number 22 to User B in lieu of a public key, and User B willreceive the public key when User B requests and receives the contactrecord corresponding to the serial number 22. As described herein, therequest by User B may require User A's approval prior to disseminatingthe contact record, and by extension the public key also. In analternate embodiment, the CRS 10 is adapted to generate a public key anda private key such that the public key is stored in a contact record,and the private key is conveyed to the user via an encrypted networkconnection (e.g., SSL).

In another embodiment, a network device 30 is adapted to detect thepresence of a public key in a contact record stored on the networkdevice. User B requests and receives User A's contact record, whichcontains a public key. In one embodiment, the network connection isencrypted—ensuring that the public key is transmitted securely. Inanother embodiment, when User B initiates electronic communication withUser A, the network device 30 detects that the communication is intendedfor User A; that the network device 30 has a contact record for User A;and that the contact record contains a public key. The network device 30may present User B with the option to encrypt User B's communicationusing User A's public key, or to digitally sign the communication usingUser B's private key. In one embodiment, when the network device detectsa public key within the contact record, it initiates an “update” requestto the CRS 10 to ensure that the public key is the most current versionbefore encrypting the communication.

In another embodiment, User A invokes the process of generating apublic/private key pair on the CRS 10 from a network device 30, suchthat the private key is retrieved by the network device and storedsecurely. When User A receives a communication encrypted by User A'scorresponding public key, the network device can retrieve the privatekey and decrypt the communication on behalf of User A. In oneembodiment, the process of storing the private key involves storing theserial number 22 of the corresponding public key with the private key,and further encrypting the private key with a pass phrase; and requiringUser A to provide the pass phrase in order to retrieve the private key.In an alternate embodiment, the network device is adapted to import theprivate key, pass phrase, and any other required data into anapplication or network device 30 that already supports PKI technology.

In another embodiment, a communication encrypted with a public key or“signed” with a private key may be transmitted along with the serialnumber 22 (e.g., via email or a network connection). When a networkdevice receives a communication signed with a private key, it mayretrieve the corresponding public key from the contact record associatedto the serial number 22. When a network device receives a communicationencrypted with a public key, the network device may retrieve thecorresponding private key or alternatively prompt the user for a passphrase prior to retrieving the corresponding private key—therebystreamlining communications using PKI technology.

The foregoing disclosure has been set forth merely to illustrate theinvention and is not intended to be limiting. Since modifications of thedisclosed embodiments incorporating the spirit and substance of theinvention may occur to persons skilled in the art, the invention shouldbe construed to include everything within the scope of the appendedclaims and equivalents thereof.

What is claimed is:
 1. A method of sorting contact records in a contactmanagement system, comprising the steps of: detecting a user accessingthe contact records; updating a time variable, a date variable, and atotal number of times accessed variable related to each of the contactrecords; communicating the updated variables to the contact managementsystem for the contact records; processing by the contact managementsystem the updated variables to form an ordinal list of the contactrecords based on recent access and frequency of access; and making theordinal list available for request by the network devices.
 2. A methodfor detecting the presence of a user on a network device, comprising thesteps of: detecting a user activity on the network device; communicatingthe user activity to a contact management system; updating a contactrecord of the contact management system associated with the user withthe user activity on the network device; and receiving an update basedon the updated contact record by a recipient.
 3. A method of utilizingan update to contact information, comprising the steps of: detecting anupdate to a contact record in a contact management system; and providingan update to a process based on the step of detecting the update to thecontact record.
 4. The method of claim 3, wherein the process is one ormore of the processes of populating an electronic form, presenting acommercial offer, and updating a subscription-based service.